ehci_hcd causes box to resume immediately after suspend to RAM

ehci_hcd causes box to resume immediately after suspend to RAM

[Rafael J. Wysocki]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Alan Stern]

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 a wakeup event has occurred.  It is 
possible to disable remote wakeup via sysfs, but it would be more 
interesting to find out the real reason for the wakeup.

I don't know how to go about doing that, however.  It might be some 
interaction at the ACPI level, and it might involve the PCI PME# 
signal.

Do you have any USB devices attached when you suspend?

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 at what "lspci -vv" says
about the controller's power management signals, both before and after
suspending the PCI device entry.  Maybe also see what ACPI reports.

Alan Stern


Index: usb-2.6/drivers/base/power/sysfs.c
===================================================================
--- usb-2.6.orig/drivers/base/power/sysfs.c
+++ usb-2.6/drivers/base/power/sysfs.c
@@ -45,10 +45,6 @@ static ssize_t state_store(struct device
 	pm_message_t state;
 	int error = -EINVAL;
 
-	/* disallow incomplete suspend sequences */
-	if (dev->bus && (dev->bus->suspend_late || dev->bus->resume_early))
-		return error;
-
 	state.event = PM_EVENT_SUSPEND;
 	/* Older apps expected to write "3" here - confused with PCI D3 */
 	if ((n == 1) && !strcmp(buf, "3"))


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Rafael J. Wysocki]

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 a wakeup event has occurred.  It is 
> possible to disable remote wakeup via sysfs, but it would be more 
> interesting to find out the real reason for the wakeup.
> 
> I don't know how to go about doing that, however.  It might be some 
> interaction at the ACPI level, and it might involve the PCI PME# 
> signal.
> 
> Do you have any USB devices attached when you suspend?

Not that I know of.

> 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 at what "lspci -vv" says
> about the controller's power management signals, both before and after
> suspending the PCI device entry.  Maybe also see what ACPI reports.

I'll be able to do this in a couple of days, when I have access to the machine
again.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Rafael J. Wysocki]

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 a wakeup event has occurred.  It is 
> possible to disable remote wakeup via sysfs, but it would be more 
> interesting to find out the real reason for the wakeup.
> 
> I don't know how to go about doing that, however.  It might be some 
> interaction at the ACPI level, and it might involve the PCI PME# 
> signal.
> 
> Do you have any USB devices attached when you suspend?
> 
> 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 at what "lspci -vv" says
> about the controller's power management signals, both before and after
> suspending the PCI device entry.

It works as expected, AFAICS.  That is, after I echo '2' to the 'state' file,
it shows that the controller is in D3.

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?

Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM

[Alan Stern]

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 at what "lspci -vv" says
> > about the controller's power management signals, both before and after
> > suspending the PCI device entry.
> 
> It works as expected, AFAICS.  That is, after I echo '2' to the 'state' file,
> it shows that the controller is in D3.

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 not sure what we 
could do with that information, and in any case there are other ways 
besides PME# for on-board devices to report wakeup requests.  I ask 
mainly out of curiousity.)

> 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 mailing list.

The simplest workaround should be to disable remote wakeup for that 
controller:

	echo disable >/sys/bus/pci/devices/.../power/wakeup

Alan Stern

Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Rafael J. Wysocki]

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 at what "lspci -vv" says
> > > about the controller's power management signals, both before and after
> > > suspending the PCI device entry.
> > 
> > It works as expected, AFAICS.  That is, after I echo '2' to the 'state' file,
> > it shows that the controller is in D3.
> 
> 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 not sure what we 
> could do with that information, and in any case there are other ways 
> besides PME# for on-board devices to report wakeup requests.  I ask 
> mainly out of curiousity.)

It shows this literally:

00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Unknown device 8089
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin D routed to IRQ 20
	Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D3 PME-Enable+ DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port

> > 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 mailing list.
> 
> The simplest workaround should be to disable remote wakeup for that 
> controller:
> 
> 	echo disable >/sys/bus/pci/devices/.../power/wakeup

I tried that but it didn't help.  Namely, the box resumed right after
suspending as it had done before.

The only way to prevent it from resuming immediately after the suspend is to
'rmmod ehci_hcd' before the suspend.

Interestingly enough, I have no such problems with EHCI on the other test box
that is able to suspend to RAM and resume.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Alan Stern]

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 not sure what we 
> > could do with that information, and in any case there are other ways 
> > besides PME# for on-board devices to report wakeup requests.  I ask 
> > mainly out of curiousity.)
> 
> It shows this literally:
> 
> 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
> 	Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> 	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Interrupt: pin D routed to IRQ 20
> 	Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K]
> 	Capabilities: [50] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> 		Status: D3 PME-Enable+ DSel=0 DScale=0 PME-
> 	Capabilities: [58] Debug port

Which means that the controller is in D3 and it supports PME#, but PME#
isn't turned on.  But as I said, Intel controllers may signal wakeup
requests in a different way (UHCI controllers definitely do, but maybe
not EHCI).

> > The simplest workaround should be to disable remote wakeup for that 
> > controller:
> > 
> > 	echo disable >/sys/bus/pci/devices/.../power/wakeup
> 
> I tried that but it didn't help.  Namely, the box resumed right after
> suspending as it had done before.
> 
> The only way to prevent it from resuming immediately after the suspend is to
> 'rmmod ehci_hcd' before the suspend.

Hmmm...  If you turn on CONFIG_USB_DEBUG, what shows up in 
/sys/class/usb_host/usb_hostN/registers where N is the bus number of 
the controller?

Also, can you post a dmesg log (with CONFIG_USB_DEBUG enabled) showing 
what happens during the suspend and immediate resume?

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Rafael J. Wysocki]

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 not sure what we 
> > > could do with that information, and in any case there are other ways 
> > > besides PME# for on-board devices to report wakeup requests.  I ask 
> > > mainly out of curiousity.)
> > 
> > It shows this literally:
> > 
> > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
> > 	Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > 	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> > 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> > 	Interrupt: pin D routed to IRQ 20
> > 	Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K]
> > 	Capabilities: [50] Power Management version 2
> > 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> > 		Status: D3 PME-Enable+ DSel=0 DScale=0 PME-
> > 	Capabilities: [58] Debug port
> 
> Which means that the controller is in D3 and it supports PME#, but PME#
> isn't turned on.  But as I said, Intel controllers may signal wakeup
> requests in a different way (UHCI controllers definitely do, but maybe
> not EHCI).
> 
> > > The simplest workaround should be to disable remote wakeup for that 
> > > controller:
> > > 
> > > 	echo disable >/sys/bus/pci/devices/.../power/wakeup
> > 
> > I tried that but it didn't help.  Namely, the box resumed right after
> > suspending as it had done before.
> > 
> > The only way to prevent it from resuming immediately after the suspend is to
> > 'rmmod ehci_hcd' before the suspend.
> 
> Hmmm...  If you turn on CONFIG_USB_DEBUG, what shows up in 
> /sys/class/usb_host/usb_hostN/registers where N is the bus number of 
> the controller?

bus pci, device 0000:00:1d.7 (driver 10 Dec 2004)
EHCI Host Controller
EHCI 1.00, hcd state 4
ownership 00000001
SMI sts/enable 0x80080000
structural params 0x00103206
capability params 0x00006871
status 1008 Halt FLR
command 010000 (park)=0 ithresh=1 period=1024 HALT
intrenable 37 IAA FATAL PCD ERR INT
uframe 36f1
port 1 status 701000 POWER sig=se0
port 2 status 701000 POWER sig=se0
port 3 status 701000 POWER sig=se0
port 4 status 701000 POWER sig=se0
port 5 status 701000 POWER sig=se0
port 6 status 701000 POWER sig=se0
irq normal 0 err 0 reclaim 0 (lost 0)
complete 0 unlink 0

> Also, can you post a dmesg log (with CONFIG_USB_DEBUG enabled) showing 
> what happens during the suspend and immediate resume?

[That's after I have disabled the wakeup on the EHCI  controller.]

PM: Preparing system for mem sleep
Stopping tasks ... done.
Suspending console(s)
pnp: Device 00:07 disabled.
pnp: Device 00:05 disabled.
ehci_hcd 0000:00:1d.7: --> PCI D3
uhci_hcd 0000:00:1d.2: uhci_suspend
uhci_hcd 0000:00:1d.2: --> PCI D0/legacy
uhci_hcd 0000:00:1d.1: uhci_suspend
uhci_hcd 0000:00:1d.1: --> PCI D0/legacy
uhci_hcd 0000:00:1d.0: uhci_suspend
uhci_hcd 0000:00:1d.0: --> PCI D0/legacy
PM: Entering mem sleep
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Back to C!
PM: Finishing wakeup.
uhci_hcd 0000:00:1d.0: PCI legacy resume
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: uhci_resume
uhci_hcd 0000:00:1d.0: uhci_check_and_reset_hc: legsup = 0x2f00
uhci_hcd 0000:00:1d.0: Performing full reset
usb usb2: root hub lost power or was reset
usb usb2: suspend_rh
uhci_hcd 0000:00:1d.1: PCI legacy resume
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: uhci_resume
uhci_hcd 0000:00:1d.1: uhci_check_and_reset_hc: legsup = 0x2000
uhci_hcd 0000:00:1d.1: Performing full reset
usb usb3: root hub lost power or was reset
usb usb3: suspend_rh
uhci_hcd 0000:00:1d.2: PCI legacy resume
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: uhci_resume
uhci_hcd 0000:00:1d.2: uhci_check_and_reset_hc: legsup = 0x2000
uhci_hcd 0000:00:1d.2: Performing full reset
usb usb4: root hub lost power or was reset
usb usb4: suspend_rh
ehci_hcd 0000:00:1d.7: PCI D0, from previous PCI D3
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1d.7 to 64
PM: Writing back config space on device 0000:00:1e.0 at offset 7 (was 2280d0d0, writing 280d0d0)
PCI: Setting latency timer of device 0000:00:1e.0 to 64
PM: Writing back config space on device 0000:00:1f.1 at offset 9 (was 0, writing 30000000)
PM: Writing back config space on device 0000:00:1f.1 at offset 1 (was 2800005, writing 2800007)
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PM: Writing back config space on device 0000:00:1f.5 at offset 1 (was 2900007, writing 2900003)
ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1f.5 to 64
eth0: link down
pnp: Device 00:05 activated.
pnp: Device 00:07 activated.
pnp: Failed to activate device 00:0b.
pnp: Failed to activate device 00:0c.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
hda: selected mode 0x42
hdb: selected mode 0x42
hdc: selected mode 0x42
usb usb1: usb resume
usb usb1: finish resume
hub 1-0:1.0: hub_resume
ehci_hcd 0000:00:1d.7: resume root hub
usb usb2: usb resume
usb usb2: finish resume
hub 2-0:1.0: hub_resume
usb usb2: wakeup_rh
usb usb3: usb resume
usb usb3: finish resume
hub 3-0:1.0: hub_resume
usb usb3: wakeup_rh
usb usb4: usb resume
usb usb4: finish resume
hub 4-0:1.0: hub_resume
usb usb4: wakeup_rh
Restarting tasks ... <7>hub 1-0:1.0: state 7 ports 6 chg 0000 evt 0000
ehci_hcd 0000:00:1d.7: GetStatus port 3 status 001020 POWER sig=se0 OCC
hub 1-0:1.0: over-current change on port 3
hub 1-0:1.0: trying to enable port power on non-switchable hub
done.
ehci_hcd 0000:00:1d.7: GetStatus port 4 status 001020 POWER sig=se0 OCC
hub 1-0:1.0: over-current change on port 4
hub 1-0:1.0: trying to enable port power on non-switchable hub
ehci_hcd 0000:00:1d.7: GetStatus port 5 status 001020 POWER sig=se0 OCC
hub 1-0:1.0: over-current change on port 5
hub 1-0:1.0: trying to enable port power on non-switchable hub
ehci_hcd 0000:00:1d.7: GetStatus port 6 status 001020 POWER sig=se0 OCC
hub 1-0:1.0: over-current change on port 6
hub 1-0:1.0: trying to enable port power on non-switchable hub
hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
usb usb2: suspend_rh (auto-stop)
usb usb3: suspend_rh (auto-stop)
usb usb4: suspend_rh (auto-stop)
hub 1-0:1.0: hub_suspend
ehci_hcd 0000:00:1d.7: suspend root hub
usb usb1: usb auto-suspend
hub 2-0:1.0: hub_suspend
usb usb2: suspend_rh
usb usb2: usb auto-suspend
hub 3-0:1.0: hub_suspend
usb usb3: suspend_rh
usb usb3: usb auto-suspend
hub 4-0:1.0: hub_suspend
usb usb4: suspend_rh
usb usb4: usb auto-suspend

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Alan Stern]

On Thu, 14 Jun 2007, Rafael J. Wysocki wrote:

> > Hmmm...  If you turn on CONFIG_USB_DEBUG, what shows up in 
> > /sys/class/usb_host/usb_hostN/registers where N is the bus number of 
> > the controller?
> 
> bus pci, device 0000:00:1d.7 (driver 10 Dec 2004)
> EHCI Host Controller
> EHCI 1.00, hcd state 4
> ownership 00000001
> SMI sts/enable 0x80080000
> structural params 0x00103206
> capability params 0x00006871
> status 1008 Halt FLR
> command 010000 (park)=0 ithresh=1 period=1024 HALT
> intrenable 37 IAA FATAL PCD ERR INT
> uframe 36f1
> port 1 status 701000 POWER sig=se0
> port 2 status 701000 POWER sig=se0
> port 3 status 701000 POWER sig=se0
> port 4 status 701000 POWER sig=se0
> port 5 status 701000 POWER sig=se0
> port 6 status 701000 POWER sig=se0
> irq normal 0 err 0 reclaim 0 (lost 0)
> complete 0 unlink 0

Nothing special there.

> > Also, can you post a dmesg log (with CONFIG_USB_DEBUG enabled) showing 
> > what happens during the suspend and immediate resume?
> 
> [That's after I have disabled the wakeup on the EHCI  controller.]
...
> Restarting tasks ... <7>hub 1-0:1.0: state 7 ports 6 chg 0000 evt 0000
> ehci_hcd 0000:00:1d.7: GetStatus port 3 status 001020 POWER sig=se0 OCC
> hub 1-0:1.0: over-current change on port 3
> hub 1-0:1.0: trying to enable port power on non-switchable hub
> done.
> ehci_hcd 0000:00:1d.7: GetStatus port 4 status 001020 POWER sig=se0 OCC
> hub 1-0:1.0: over-current change on port 4
> hub 1-0:1.0: trying to enable port power on non-switchable hub
> ehci_hcd 0000:00:1d.7: GetStatus port 5 status 001020 POWER sig=se0 OCC
> hub 1-0:1.0: over-current change on port 5
> hub 1-0:1.0: trying to enable port power on non-switchable hub
> ehci_hcd 0000:00:1d.7: GetStatus port 6 status 001020 POWER sig=se0 OCC
> hub 1-0:1.0: over-current change on port 6
> hub 1-0:1.0: trying to enable port power on non-switchable hub

That's odd.  Where could these overcurrent changes be coming from?  
And how come they don't show up on ports 1 and 2?

There's an excellent chance that they are responsible for your 
immediate resumes.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Benjamin Herrenschmidt]

> That's odd.  Where could these overcurrent changes be coming from?  
> And how come they don't show up on ports 1 and 2?
> 
> There's an excellent chance that they are responsible for your 
> immediate resumes.

I've seen quirks in Apple drivers a while ago where they tried to avoid
suspending some of the RH ports... possibly bcs they aren't connected to
anything and trying to suspend them does bad things. I wonder if maybe
ACPI might carry similar kind of informations...

Ben.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Alan Stern]

On Tue, 25 Sep 2007, Benjamin Herrenschmidt wrote:

> > That's odd.  Where could these overcurrent changes be coming from?  
> > And how come they don't show up on ports 1 and 2?
> > 
> > There's an excellent chance that they are responsible for your 
> > immediate resumes.
> 
> I've seen quirks in Apple drivers a while ago where they tried to avoid
> suspending some of the RH ports... possibly bcs they aren't connected to
> anything and trying to suspend them does bad things.

That is certainly possible.  I have seen exactly the same sort of thing
on some HP systems, where (1) the overcurrent inputs for unused ports
are permanently wired high, and (2) a bug in the Intel UHCI controller
causes a resume event whenever any port has an overcurrent condition!

>  I wonder if maybe
> ACPI might carry similar kind of informations...

I wouldn't know where to look.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Zhang Rui]

> > > 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 mailing list.
> > 
> > The simplest workaround should be to disable remote wakeup for that 
> > controller:
> > 
> > 	echo disable >/sys/bus/pci/devices/.../power/wakeup
> 
> I tried that but it didn't help.  Namely, the box resumed right after
> suspending as it had done before.
> 
> The only way to prevent it from resuming immediately after the suspend is to
> 'rmmod ehci_hcd' before the suspend.
> 
> Interestingly enough, I have no such problems with EHCI on the other test box
> that is able to suspend to RAM and resume.
> 
What's the kernel version you are using?
Is it the same problem shown here?
http://lkml.org/lkml/2007/5/18/55
2.6.22-rc1-mm1 may have this problem.


Thanks,
Rui

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Rafael J. Wysocki]

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 mailing list.
> > > 
> > > The simplest workaround should be to disable remote wakeup for that 
> > > controller:
> > > 
> > > 	echo disable >/sys/bus/pci/devices/.../power/wakeup
> > 
> > I tried that but it didn't help.  Namely, the box resumed right after
> > suspending as it had done before.
> > 
> > The only way to prevent it from resuming immediately after the suspend is to
> > 'rmmod ehci_hcd' before the suspend.
> > 
> > Interestingly enough, I have no such problems with EHCI on the other test box
> > that is able to suspend to RAM and resume.
> > 
> What's the kernel version you are using?
> Is it the same problem shown here?
> http://lkml.org/lkml/2007/5/18/55
> 2.6.22-rc1-mm1 may have this problem.

Yes, I remeber this thread.

The kernel is 2.6.22-rc4 with the patches from
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc4/patches/
applied.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM

[Rafael J. Wysocki]

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 that?
> > > > 
> > > > I wish I knew.  Maybe you can try asking on the ACPI mailing list.
> > > > 
> > > > The simplest workaround should be to disable remote wakeup for that 
> > > > controller:
> > > > 
> > > > 	echo disable >/sys/bus/pci/devices/.../power/wakeup
> > > 
> > > I tried that but it didn't help.  Namely, the box resumed right after
> > > suspending as it had done before.
> > > 
> > > The only way to prevent it from resuming immediately after the suspend is to
> > > 'rmmod ehci_hcd' before the suspend.
> > > 
> > > Interestingly enough, I have no such problems with EHCI on the other test box
> > > that is able to suspend to RAM and resume.
> > > 
> > What's the kernel version you are using?
> > Is it the same problem shown here?
> > http://lkml.org/lkml/2007/5/18/55
> > 2.6.22-rc1-mm1 may have this problem.
> 
> Yes, I remeber this thread.

s/remeber/remember/

> The kernel is 2.6.22-rc4 with the patches from
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc4/patches/
> applied.
> 
> Greetings,
> Rafael
 

-- 
"Premature optimization is the root of all evil." - Donald Knuth

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel