Hi,
It seems there's a problem with USB OHCI driver that causes these traces to
appear on suspend on an AMD64-based box:
..7PM: Image restored successfully.
PCI: Setting latency timer of device :00:02.0 to 64
ohci_hcd :00:02.0: HC died; cleaning up
usb 1-2: USB disconnect, address 3
On Thursday 30 of September 2004 23:58, David Brownell wrote:
On Thursday 30 September 2004 1:51 pm, Rafael J. Wysocki wrote:
Hi,
It seems there's a problem with USB OHCI driver that causes these traces
to
appear on suspend on an AMD64-based box:
Not all parts of power management
On Monday 04 of October 2004 14:22, Jan De Luyck wrote:
[-- snip --]
Does cat /proc/bus/usb/devices give you an empty file or does it hang?
Is that modular USB or is it compiled into the kernel? OHCI or UHCI?
UHCI. I just did a test-suspend-resume, currently plugged USB devices don't
work,
Hi,
There seems to be a problem in 2.6.10-rc1-mm4 with either USB storage (eg a
pendrive) or hotplug on AMD64 (NForce3 chipset, ohci-hcd, SuSE 9.1). Namely,
if a USB pendrive is inserted into a socket, the kernel does not even detect
it. Here's what appears in dmesg after it's inserted:
On Wednesday 10 of November 2004 14:58, David Brownell wrote:
On Wednesday 10 November 2004 02:54, Rafael J. Wysocki wrote:
Hi,
There seems to be a problem in 2.6.10-rc1-mm4 with either USB storage (eg
a
pendrive) or hotplug on AMD64 (NForce3 chipset, ohci-hcd, SuSE 9.1).
Namely
On Wednesday 10 of November 2004 16:36, David Brownell wrote:
On Wednesday 10 November 2004 06:57, Rafael J. Wysocki wrote:
On Wednesday 10 of November 2004 14:58, David Brownell wrote:
I recently posted several USB PM fixes that make things work better
in my testing, and it sounds like
Hi,
On Wednesday, 28 of September 2005 22:23, David Brownell wrote:
BTW, please have a look at:
http://bugzilla.kernel.org/show_bug.cgi?id=4416#c36
and
http://bugzilla.kernel.org/show_bug.cgi?id=4416#c37
What's with the bogus dates in those reports ... claiming some of you
Hi,
On Wednesday, 28 of September 2005 22:56, David Brownell wrote:
On Wednesday, 28 of September 2005 22:23, David Brownell wrote:
BTW, please have a look at:
http://bugzilla.kernel.org/show_bug.cgi?id=4416#c36
and
http://bugzilla.kernel.org/show_bug.cgi?id=4416#c37
Hi,
On Wednesday, 28 of September 2005 23:07, David Brownell wrote:
ok. i didn't look too close, but i think ohci-hcd does not fully disable
interrupts in it's suspend callback...needs a closer look.
cc:ing linux-usb-devel...
It's handled in hcd-pci.c ... All PCI based HCDs
Hi,
On Monday, 17 of October 2005 20:54, Alan Stern wrote:
On Mon, 17 Oct 2005, Pavel Machek wrote:
Hi!
In -mm, usb breaks suspend to disk. Compiled without
CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
actually tries to suspend USB, but it fails and machine
Hi,
On Tuesday, 18 of October 2005 03:01, Alan Stern wrote:
On Mon, 17 Oct 2005, Rafael J. Wysocki wrote:
On Monday, 17 of October 2005 20:54, Alan Stern wrote:
On Mon, 17 Oct 2005, Pavel Machek wrote:
Hi!
In -mm, usb breaks suspend to disk. Compiled without
Hi,
On Wednesday, 19 of October 2005 18:18, Alan Stern wrote:
[Trimmed the CC: list]
}-- snip --{
Stopping tasks: |
Freeing memory... done (14642 pages freed)
Suspending device card0-0
Suspending device 2-2:1.0
Suspending device 2-2
Suspending
Hi,
On Wednesday, 19 of October 2005 22:46, Alan Stern wrote:
On Wed, 19 Oct 2005, Rafael J. Wysocki wrote:
}-- snip --{
There has been a lot of development on USB
suspend/resume in 2.6.14, and you don't have all the patches applied. In
particular, you are missing usb-pm-05.patch
The ehci_hcd driver causes problems like this:
ehci_hcd :00:02.2: EHCI Host Controller
ehci_hcd :00:02.2: debug port 1
ehci_hcd :00:02.2: new USB bus registered, assigned bus number 3
ehci_hcd :00:02.2: irq 5, io mem 0xfebfdc00
usb 2-2: Product: USB Receiver
usb 2-2: Manufacturer:
On Sunday, 11 December 2005 21:38, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
The ehci_hcd driver causes problems like this:
ehci_hcd :00:02.2: EHCI Host Controller
ehci_hcd :00:02.2: debug port 1
ehci_hcd :00:02.2: new USB bus registered, assigned
On Monday, 12 December 2005 21:29, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Sunday, 11 December 2005 21:38, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
The ehci_hcd driver causes problems like this:
ehci_hcd :00:02.2: EHCI
On Monday, 12 December 2005 22:09, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
It's best to actually send a copy of line 620 - kernels vary a lot, and
many developers won't have that particualr -mm tree handy.
The way I normally do this is to do `gdb vmlinux
On Tuesday, 13 December 2005 07:52, David Brownell wrote:
if ((status STS_PCD) device_may_wakeup(hcd-self.root_hub-dev)) {
What happens if you make that line read
if ((status STS_PCD) != 0) {
and ignore the root hub thing?
So far, so good. It works and hasn't triggered
On Tuesday, 13 December 2005 23:22, David Brownell wrote:
On Tuesday 13 December 2005 2:10 pm, Rafael J. Wysocki wrote:
On Tuesday, 13 December 2005 07:52, David Brownell wrote:
if ((status STS_PCD)
device_may_wakeup(hcd-self.root_hub-dev)) {
What happens if you
On Monday 13 February 2006 13:02, Takashi Iwai wrote:
At Sun, 12 Feb 2006 19:05:20 -0800,
Andrew Morton wrote:
- Patrizio Bassi [EMAIL PROTECTED] has an alsa suspend
regression (alsa suspend/resume continues to fail for ens1370)
It's not a regression. PM didn't work with ens1370 at
On Monday 13 February 2006 14:51, Takashi Iwai wrote:
At Mon, 13 Feb 2006 14:09:51 +0100,
Rafael J. Wysocki wrote:
On Monday 13 February 2006 13:02, Takashi Iwai wrote:
At Sun, 12 Feb 2006 19:05:20 -0800,
Andrew Morton wrote:
- Patrizio Bassi [EMAIL PROTECTED] has an alsa
Hi,
On Monday 24 April 2006 23:29, David Brownell wrote:
I've noticed a bunch of problem reports that go like this:
- boot system with some USB devices attached
- echo disk /sys/power/state
- ... later resume ...
- now those USB devices don't work right
- unplug them/replug them,
Hi,
On Tuesday 25 April 2006 00:31, Nigel Cunningham wrote:
On Tuesday 25 April 2006 07:29, David Brownell wrote:
I've noticed a bunch of problem reports that go like this:
- boot system with some USB devices attached
- echo disk /sys/power/state
- ... later resume ...
- now
Hi,
On Tuesday 25 April 2006 18:11, David Brownell wrote:
On Tuesday 25 April 2006 1:32 am, Rafael J. Wysocki wrote:
just want things quiesced, mainly because we don't want to spin down
drives.
That's right. And kernel_restart_prepare(NULL) will make them spin down?
If so
Hi,
On Tuesday 25 April 2006 22:28, Nigel Cunningham wrote:
On Wednesday 26 April 2006 04:56, Rafael J. Wysocki wrote:
You're saying that (9) is wrong, so could you please suggest what to do
instead of it?
'scuse me for butting in, but here's my suggested modified version:
Well
On Tuesday 25 April 2006 23:04, David Brownell wrote:
On Tuesday 25 April 2006 11:56 am, Rafael J. Wysocki wrote:
I've begun thinking that calls like pm_should_I_spin_down_drives() would
be a
better structural approach than continually redefining this freeze
thing so
it makes
Hi,
On Tuesday 25 April 2006 23:03, Nigel Cunningham wrote:
On Wednesday 26 April 2006 06:53, Rafael J. Wysocki wrote:
On Tuesday 25 April 2006 22:28, Nigel Cunningham wrote:
On Wednesday 26 April 2006 04:56, Rafael J. Wysocki wrote:
You're saying that (9) is wrong, so could you please
Hi,
On Wednesday 26 April 2006 00:18, Nigel Cunningham wrote:
On Wednesday 26 April 2006 08:06, Rafael J. Wysocki wrote:
On Tuesday 25 April 2006 23:03, Nigel Cunningham wrote:
On Wednesday 26 April 2006 06:53, Rafael J. Wysocki wrote:
On Tuesday 25 April 2006 22:28, Nigel Cunningham
On Wednesday 26 April 2006 00:56, David Brownell wrote:
On Tuesday 25 April 2006 2:55 pm, Rafael J. Wysocki wrote:
On Tuesday 25 April 2006 23:04, David Brownell wrote:
The third state is the problem scenario, kicking in when the driver was
statically linked (or modprobed from
On Wednesday 26 April 2006 16:38, Alan Stern wrote:
On Wed, 26 Apr 2006, Rafael J. Wysocki wrote:
Now, if you have specific examples of things that shouldn't be reset, that
could be interesting.
The resume device and friends (ie. controller, bus, etc.).
I presume the freeze/reset
On Wednesday 26 April 2006 17:38, Alan Stern wrote:
On Wed, 26 Apr 2006, Rafael J. Wysocki wrote:
So under these circumstances, how does it hurt anything to reset the
resume device rather than to freeze it?
It just shouldn't be necessary. Actually I think the resume device
On Wednesday 26 April 2006 21:06, Alan Stern wrote:
On Wed, 26 Apr 2006, Rafael J. Wysocki wrote:
It just shouldn't be necessary. Actually I think the resume device
shouldn't
be frozen too.
Well, you wouldn't want it doing DMA to unknown memory areas while you're
trying
On Wednesday 26 April 2006 23:31, David Brownell wrote:
On Wednesday 26 April 2006 4:26 am, Rafael J. Wysocki wrote:
On Wednesday 26 April 2006 00:56, David Brownell wrote:
But it's not the root cause of the problem either. The same problem
appears if
the device holding the resume
On Saturday 20 May 2006 23:30, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday 20 May 2006 14:41, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm2/
My box (Asus L5D, x86_64 kernel) locks
On Thursday 25 May 2006 22:29, Alan Stern wrote:
On Sun, 21 May 2006, Rafael J. Wysocki wrote:
On Saturday 20 May 2006 23:30, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday 20 May 2006 14:41, Andrew Morton wrote:
ftp://ftp.kernel.org
On Friday 26 May 2006 05:06, David Brownell wrote:
On Tuesday 02 May 2006 9:12 am, Patrick Mochel wrote:
On Thu, Apr 27, 2006 at 12:41:28PM -0700, David Brownell wrote:
There does seem to be agreement that the current FREEZE invocation is not
sufficient. I'm looking at a slightly
On Friday 02 June 2006 06:19, David Brownell wrote:
On Thursday 01 June 2006 8:46 pm, Andrew Morton wrote:
fyi, I continue to revert this patch from Greg's tree.
Here's a somewhat better version, FYI. Still has some issues,
but seemingly nothing quite as nasty as Rafael reported.
On Friday 14 July 2006 07:48, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm2/
- Patches were merged, added, dropped and fixed. Nothing particularly
exciting.
This happens on my box at startup, every time:
ehci_hcd
On Friday 14 July 2006 20:36, Michal Piotrowski wrote:
Hi Andrew,
On 14/07/06, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 14 Jul 2006 13:36:08 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Unable to handle kernel NULL pointer dereference at 0038 RIP
On Friday, 8 September 2006 10:13, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
ohci_hcd doesn't work after a resume from disk on HPC nx6325, worked on
2.6.18-rc5-mm1.
It helps if I rmmod and modprobe it after the resume.
On Friday, 8 September 2006 22:44, Alan Stern wrote:
On Fri, 8 Sep 2006, Andrew Morton wrote:
Alan, is this likely to be due to your USB PM changes?
It's possible. Most of those changes are innocuous. They add routines
that don't get used until a later patch. However one of them might
On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote:
On Friday, 8 September 2006 22:44, Alan Stern wrote:
On Fri, 8 Sep 2006, Andrew Morton wrote:
Alan, is this likely to be due to your USB PM changes?
It's possible. Most of those changes are innocuous. They add routines
On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote:
On Friday, 8 September 2006 22:44, Alan Stern wrote:
On Fri, 8 Sep 2006, Andrew Morton wrote:
Alan, is this likely to be due to your USB PM changes?
It's possible. Most of those changes are innocuous. They add routines
On Wednesday, 13 September 2006 14:07, Rafael J. Wysocki wrote:
On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote:
On Friday, 8 September 2006 22:44, Alan Stern wrote:
On Fri, 8 Sep 2006, Andrew Morton wrote:
Alan, is this likely to be due to your USB PM changes
On Tuesday, 12 September 2006 09:06, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every
time (happens also on -rc6-mm1, does not happen on -rc7):
Unable to
On Wednesday, 13 September 2006 15:58, Rafael J. Wysocki wrote:
On Tuesday, 12 September 2006 09:06, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every
On Tuesday, 12 September 2006 22:10, Alan Stern wrote:
On Tue, 12 Sep 2006, Mattia Dongili wrote:
No luck here. I'll give -mm2 a run just to
full dmesg
with patch applied[1]:
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3-2
without it (it's almost identical :)):
On Wednesday, 13 September 2006 20:44, Alan Stern wrote:
On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every
time (happens also on -rc6-mm1, does not happen on -rc7):
Unable to handle kernel NULL pointer dereference
On Wednesday, 13 September 2006 20:38, Alan Stern wrote:
On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
Well, I have reproduced it with
gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
reverted too.
Attached is the output of dmesg from the failing case with USB_DEBUG set
On Wednesday, 13 September 2006 23:01, Alan Stern wrote:
On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
The patch below will add some extra debugging information. We need to
find out why the resume didn't succeed. Oh -- and of course, you should
reinstate all those autosuspend patches
On Thursday, 14 September 2006 00:31, Pete Zaitcev wrote:
On Wed, 13 Sep 2006 14:44:48 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
This problem has already been identified by Pete Zaitcev in this thread:
http://marc.theaimsgroup.com/?t=11576951281r=1w=2
Perhaps Pete
On Wednesday, 13 September 2006 23:55, Alan Stern wrote:
On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
Try this patch instead. It looks for problems occurring a little earlier
in the call chain.
I've applied both patches at a time (I hope they don't conflict).
The dmesg output
On Thursday, 14 September 2006 15:14, Rafael J. Wysocki wrote:
On Wednesday, 13 September 2006 23:55, Alan Stern wrote:
On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
Try this patch instead. It looks for problems occurring a little
earlier
in the call chain.
I've applied
On Thursday, 14 September 2006 17:04, Alan Stern wrote:
On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
Try adding some ehci_dbg() lines in there (copy the form of the line
just
after restart:). We want to follow the value of
hcd-self.root_hub-state. Initially it should
On Thursday, 14 September 2006 18:17, Alan Stern wrote:
On Thu, 14 Sep 2006, Alan Stern wrote:
Now of course, the autosuspend stuff has to work properly no matter what
the kernel configuration is. I'll go back and rebuild the drivers with
USB_SUSPEND turned off and see what happens.
On Thursday, 14 September 2006 19:08, Rafael J. Wysocki wrote:
On Thursday, 14 September 2006 18:17, Alan Stern wrote:
On Thu, 14 Sep 2006, Alan Stern wrote:
Now of course, the autosuspend stuff has to work properly no matter what
the kernel configuration is. I'll go back and rebuild
On Thursday, 14 September 2006 19:22, Alan Stern wrote:
On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
Now USB didn't work after the first resume (kernel configured with
USB_SUSPEND
unset).
The dmesg output is attached.
This is getting too confusing. :-(
Sorry for the confusion
On Thursday, 14 September 2006 20:28, Alan Stern wrote:
On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
Let's try a simpler test. Leave USB_SUSPEND unset.
First rmmod ohci-hcd. None of your full-speed USB devices will work, but
that's okay. Try the suspend-twice test and see what
On Thursday, 14 September 2006 21:37, Rafael J. Wysocki wrote:
On Thursday, 14 September 2006 20:28, Alan Stern wrote:
On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
Let's try a simpler test. Leave USB_SUSPEND unset.
First rmmod ohci-hcd. None of your full-speed USB devices
On Thursday, 14 September 2006 22:55, Alan Stern wrote:
On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
Well, sorry. This test has been passed, but after a reboot it refused to
suspend just once giving the same messages that I've got from the kernel
with USB_SUSPEND set (the relevant dmesg
Hi,
It looks like the ohci_hcd driver sometimes has problems with the
initialization (eg. USB mouse doesn't work after a fresh boot and reloading
of the driver helps).
I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D),
but it is not readily reproducible. Anyway I've got a
Hi,
On Saturday, 16 September 2006 00:13, Rafael J. Wysocki wrote:
It looks like the ohci_hcd driver sometimes has problems with the
initialization (eg. USB mouse doesn't work after a fresh boot and reloading
of the driver helps).
I have observed this on two different x86_64 boxes (HPC 6325
On Saturday, 16 September 2006 00:45, Pete Zaitcev wrote:
On Thu, 14 Sep 2006 13:19:53 +0200, Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
In fact I can reproduce it on two different boxes now.
How about the attached?
Apparently works. :-)
Thanks,
Rafael
--
You never change things
On Saturday, 16 September 2006 10:13, Rafael J. Wysocki wrote:
On Saturday, 16 September 2006 00:13, Rafael J. Wysocki wrote:
It looks like the ohci_hcd driver sometimes has problems with the
initialization (eg. USB mouse doesn't work after a fresh boot and reloading
of the driver helps
On Monday, 18 September 2006 08:50, Jan De Luyck wrote:
On Monday 18 September 2006 08:27, Rafael J. Wysocki wrote:
On Saturday, 16 September 2006 10:13, Rafael J. Wysocki wrote:
On Saturday, 16 September 2006 00:13, Rafael J. Wysocki wrote:
It looks like the ohci_hcd driver sometimes
On Monday, 18 September 2006 17:07, Alan Stern wrote:
On Mon, 18 Sep 2006, Rafael J. Wysocki wrote:
Actually, the problem is ohci_hcd doesn't seem to recognize devices
plugged
into the USB ports.
For example, if I unplug and replug a mouse (that worked before
unplugging
On Tuesday, 19 September 2006 02:04, David Brownell wrote:
On Friday 15 September 2006 3:13 pm, Rafael J. Wysocki wrote:
Hi,
It looks like the ohci_hcd driver sometimes has problems with the
initialization (eg. USB mouse doesn't work after a fresh boot and reloading
of the driver helps
On Friday, 22 September 2006 17:18, Alan Stern wrote:
On Fri, 22 Sep 2006, Rafael J. Wysocki wrote:
I have tested 2.6.18-rc6-mm2 with your patch applied (it is called
2.6.18-rc6
in the attached dmesg outputs, but that's because I have a customized
2.6.18-rc6-mm2 installed and I didn't
Hi,
On Monday, 25 September 2006 21:40, Alan Stern wrote:
Greg and Andrew:
This series of patches completely reworks the way ohci-hcd carries out
root-hub autosuspends. The existing code is not compatible with the new
core USB autosuspend mechanism.
Patch 1 is a simple one-line change
Hi,
On Sunday, 1 April 2007 20:34, Pavel Machek wrote:
Hi!
Problem is that suspending _with_ removable mass storage devices
attached just will not work. User will unplug them, then complain
about corruption. Advanced user will unplug them, work with them
somewhere else, replug
On Monday, 2 April 2007 04:54, Alan Stern wrote:
On Sun, 1 Apr 2007, Rafael J. Wysocki wrote:
Hi,
On Sunday, 1 April 2007 20:34, Pavel Machek wrote:
Hi!
Problem is that suspending _with_ removable mass storage devices
attached just will not work. User will unplug them
On Wednesday, 23 May 2007 09:48, Andrew Morton wrote:
On Wed, 23 May 2007 00:42:33 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
This is intermittently getting resume-from-RAM failures. It is not
On Saturday, 2 June 2007 00:12, Andrew Morton wrote:
On Fri, 1 Jun 2007 14:08:37 -0700
[EMAIL PROTECTED] wrote:
Please follow up via emailed reply-to-all, rather than via the bugzilla web
interface, thanks.
Michal, please track this as a post-2.6.21 regression.
Hi,
One of my test boxes suspends to RAM just fine except that if ehci_hcd is
loaded before the suspend, the box resumes immediately after going to sleep.
Greetings,
Rafael
--
Premature optimization is the root of all evil. - Donald Knuth
On Sunday, 3 June 2007 17:31, Alan Stern wrote:
On Sun, 3 Jun 2007, Rafael J. Wysocki wrote:
Hi,
One of my test boxes suspends to RAM just fine except that if ehci_hcd is
loaded before the suspend, the box resumes immediately after going to sleep.
Evidently the hardware thinks
On Sunday, 3 June 2007 17:31, Alan Stern wrote:
On Sun, 3 Jun 2007, Rafael J. Wysocki wrote:
Hi,
One of my test boxes suspends to RAM just fine except that if ehci_hcd is
loaded before the suspend, the box resumes immediately after going to sleep.
Evidently the hardware thinks
-By : Rafael J. Wysocki [EMAIL PROTECTED]
Patch :
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/21-firewire-implement-suspend-resume-hooks.patch
Status : patch available
The patch is already in 2.6.22-rc4, AFAICS.
Greetings,
Rafael
--
Premature optimization
Hi,
The following series of patches removes some unused and unnecessary features
from the suspend and resume core code.
Comments welcome.
Greetings,
Rafael
--
Premature optimization is the root of all evil. - Donald Knuth
From: Rafael J. Wysocki [EMAIL PROTECTED]
The saved_state member of struct dev_pm_info, defined in include/linux/pm.h, is
not used anywhere, so it can be removed.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
include/linux/pm.h |1 -
1 file changed, 1 deletion(-)
Index: linux
From: Rafael J. Wysocki [EMAIL PROTECTED]
Reduce code duplication in drivers/base/suspend.c by introducing a separate
function for printing diagnostic messages.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/suspend.c | 49
From: Rafael J. Wysocki [EMAIL PROTECTED]
The pm_parent member of struct dev_pm_info (defined in include/linux/pm.h) is
only used to check if the device's parent is in the right state while the
device is being suspended or resumed. However, this can be done just as well
with the help
From: Rafael J. Wysocki [EMAIL PROTECTED]
The suspend and resume support in struct device_type (include/linux/device.h)
is not used anywhere. It is also undocumented, so it can be removed.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/resume.c |5 -
drivers
From: Rafael J. Wysocki [EMAIL PROTECTED]
The prev_state member of struct dev_pm_info (defined in include/linux/pm.h) is
only used during a resume to check if the device's state before the suspend was
'off', in which case the device is not resumed. However, in such cases the
decision whether
From: Rafael J. Wysocki [EMAIL PROTECTED]
The checks if the device's parent is in the right state done in
drivers/base/power/suspend.c and drivers/base/power/resume.c serve no particular
purpose, since if the parent is in a wrong power state, the device's suspend or
resume callbacks are supposed
From: Rafael J. Wysocki [EMAIL PROTECTED]
The suspend routines should be called for every device during a system sleep
transition, regardless of the device's state, so that drivers can regard these
method calls as notifications that the system is about to go to sleep, rather
than as directives
On Monday, 11 June 2007 17:59, Alan Stern wrote:
On Mon, 11 Jun 2007, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The pm_parent member of struct dev_pm_info (defined in include/linux/pm.h)
is
only used to check if the device's parent is in the right state
On Saturday, 9 June 2007 23:26, Alan Stern wrote:
On Sat, 9 Jun 2007, Rafael J. Wysocki wrote:
You can try using the patch below to see what happens when you manually
suspend the controller. It enables PCI devices to respond to the
legacy power/state attribute. You should look
On Monday, 11 June 2007 20:52, Rafael J. Wysocki wrote:
On Monday, 11 June 2007 17:59, Alan Stern wrote:
On Mon, 11 Jun 2007, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The pm_parent member of struct dev_pm_info (defined in
include/linux/pm.h) is
only
On Tuesday, 12 June 2007 03:50, Zhang Rui wrote:
I've tried to suspend with the controller in that state, but it's
resumed
immediately, as before.
Maybe also see what ACPI reports.
How can I see that?
I wish I knew. Maybe you can try asking on the ACPI
On Tuesday, 12 June 2007 13:59, Rafael J. Wysocki wrote:
On Tuesday, 12 June 2007 03:50, Zhang Rui wrote:
I've tried to suspend with the controller in that state, but it's
resumed
immediately, as before.
Maybe also see what ACPI reports.
How can I see
On Monday, 11 June 2007 22:10, Alan Stern wrote:
On Mon, 11 Jun 2007, Rafael J. Wysocki wrote:
At that point, does lspci -vv show that the controller is trying to
signal a wakeup event? That is, is the PME# signal asserted?
(Not that knowing this will help very much -- I'm
On Wednesday, 20 June 2007 16:01, Alan Stern wrote:
On Wed, 20 Jun 2007, Mattia Dongili wrote:
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/
Hello,
on this vaio sz72b I
On Wednesday, 20 June 2007 17:38, Mattia Dongili wrote:
On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote:
On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote:
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel
On Wednesday, 20 June 2007 22:50, Rafael J. Wysocki wrote:
On Wednesday, 20 June 2007 17:38, Mattia Dongili wrote:
On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote:
On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote:
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew
On Thursday, 21 June 2007 00:03, Rafael J. Wysocki wrote:
On Wednesday, 20 June 2007 22:50, Rafael J. Wysocki wrote:
On Wednesday, 20 June 2007 17:38, Mattia Dongili wrote:
On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote:
On Wednesday, 20 June 2007 07:22, Mattia Dongili
On Thursday, 21 June 2007 21:39, Alan Stern wrote:
On Thu, 21 Jun 2007, Rafael J. Wysocki wrote:
I'll see if I can reproduce your problem here.
Yes, I can. It's only necessary to load usb-storage (without any devices
actually using it) and it fails device_suspend() immediately (I
On Thursday, 9 August 2007 16:43, Alan Stern wrote:
On Thu, 9 Aug 2007, Mariusz Kozlowski wrote:
Hello,
Happens every time I reattach usb pen drive.
usb 1-2: new high speed USB device using ehci_hcd and address 10
usb 1-2: configuration #1 chosen from 1 choice
scsi6 : SCSI
of it.
I think that something like the appended patch is necessary.
Mariusz, please see if that helps.
Yes - this patch fixes the bug.
OK, thanks for the confirmation.
Here it goes again with a changelog etc.
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Fix a bug in freezer
98 matches
Mail list logo
