Remote wake up not working

Remote wake up not working

[rasmit.ranjan]

[-- Attachment #1.1: Type: text/plain, Size: 790 bytes --]

Hi,
    I am using ACER Aspire 3003LC laptop. Linux version: 2.6.15.4. I my
Host Controller supports Power Management.I tried selective
suspend/resume and it worked properly.Also my Host Controller supports
remote wake up. So i tried testing remote wake up.But it did not
work.Then i tried the same with the standard ( OHCI controller of my
laptop ).It did not work as wel. 
Then i changed my laptop and tried testing remote wakeup and it worked
properly with the OHCI controller and also with my Host Controller. 
 
So does this mean that there is something wrong with the ACER Aspire
3003LC laptop ? 
Or is there something on which remote wake up depends on besides the
Host Controller and the device ( supporting remote wake up ) ?
 
Please suggest.
 
Thanks,
Rasmit.

[-- Attachment #1.2: Type: text/html, Size: 2107 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Remote wake up not working

[David Brownell]

On Thursday 08 June 2006 5:21 am, rasmit.ranjan@wipro.com wrote:
> Hi,

[ don't cc "digest" lists ... and avoid ccing multiple lists! ]


>     I am using ACER Aspire 3003LC laptop. Linux version: 2.6.15.4. I my
> Host Controller supports Power Management.  

That's with a SIS southbridge, right?  With both EHCI and OHCI?

> I tried selective 
> suspend/resume and it worked properly.  Also my Host Controller supports
> remote wake up.  So i tried testing remote wake up.  But it did not
> work.  Then i tried the same with the standard ( OHCI controller of my
> laptop ).  It did not work as wel.

You should include specifics of how you tested, and the failure mode...

Also the "lspci -vv" output, and the relevant parts of kernel config.
(Presumably CONFIG_PM is defined, also CONFIG_USB_SUSPEND...)  And to
be most useful, the "lsusb -v" output for the devices you're using as
wakeup event sources.  (Not all USB devices behave yet for suspend/resume,
or issue wakeup events.)

Note that remote wakeup -- from e.g. a system standby or suspend-to-RAM
state -- on x86 hardware probably involves ensuring that /proc/acpi/wakeup
lists the USB controllers as wakeup sources.


> Then i changed my laptop and tried testing remote wakeup and it worked
> properly with the OHCI controller and also with my Host Controller. 

That is, using a different southbridge?  And different BIOS, with
different ACPI support?  Again, you'd need to provide specifics.

Congratulations!!  So far, every time I've tested remote wakeup on
Linux, the ACPI code broke during the resume process ... that is, if
it managed to enter a "standby" or "suspend-to-ram" state in the first
place (again, ACPI problems).  I know that USB was doing the right
thing, since that can be unit tested outside of system sleep states.

  
> So does this mean that there is something wrong with the ACER Aspire
> 3003LC laptop ?
> Or is there something on which remote wake up depends on besides the
> Host Controller and the device ( supporting remote wake up ) ?

My first guess would be you're seeing ACPI breakage, or perhaps you're
not setting things up correctly.  If you really did the same tests
on both laptops, I'd be more inclined to suspect ACPI ... especially
since that's where the problems have always been in my testing.

- Dave

Re: Remote wake up not working

[Pavel Machek]

Hi!

>     I am using ACER Aspire 3003LC laptop. Linux version: 2.6.15.4. I my
> Host Controller supports Power Management.I tried selective
> suspend/resume and it worked properly.Also my Host Controller supports
> remote wake up. So i tried testing remote wake up.But it did not
> work.Then i tried the same with the standard ( OHCI controller of my
> laptop ).It did not work as wel. 
> Then i changed my laptop and tried testing remote wakeup and it worked
> properly with the OHCI controller and also with my Host Controller. 
>  
> So does this mean that there is something wrong with the ACER Aspire
> 3003LC laptop ? 
> Or is there something on which remote wake up depends on besides the
> Host Controller and the device ( supporting remote wake up ) ?

I do not think we support remote wakeup these days. Code may be there,
but as noone ever uses it... perhaps it needs some fixing.

-- 
Thanks for all the (sleeping) penguins.

Re: Remote wake up not working

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 390 bytes --]

On Sat, 2006-06-10 at 13:28 +0000, Pavel Machek wrote:

> I do not think we support remote wakeup these days. Code may be there,
> but as noone ever uses it... perhaps it needs some fixing.

Works fine with bluetooth on my powerbook, but then again, I can't turn
it *off* which is rather annoying, but I think caused by the missing
suspend/resume handlers in hci_usb :/

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] Remote wake up not working

[David Brownell]

On Tuesday 13 June 2006 9:12 am, Johannes Berg wrote:
> On Sat, 2006-06-10 at 13:28 +0000, Pavel Machek wrote:
> 
> > I do not think we support remote wakeup these days. Code may be there,
> > but as noone ever uses it... perhaps it needs some fixing.
> 
> Works fine with bluetooth on my powerbook, but then again, I can't turn
> it *off* which is rather annoying, but I think caused by the missing
> suspend/resume handlers in hci_usb :/

USB remote wakeup basically works today (given CONFIG_USB_SUSPEND),
and has worked for quite a few kernel releases now, given

  (a) Working platform support.  So for example ACPI will not-infrequently
      do the wrong thing on resume, or the video driver misbehaves, and
      so on.  All too few systems work correctly with either (a1) "standby"
      or (a2) "mem" when you write them to /sys/power/state, and the issues
      have only rarely been related to USB.  (I got some mail over the last
      few days about one that boiled down to interrupt controller bugs.)

  (b) Support in the USB drivers for suspend/resume.  I've seen other
      reports lately about hci_usb is missing usb suspend/resume calls,
      leading to misbehavior.  (I think someone checked in an odd patch
      a while ago which change the failure mode for those missing calls
      to something that was still broken, just not as obviously.)  And
      then there are the ALSA drivers, and quite a few others...

That's not to say that it's perfect -- the clock framework is still missing
a hook to help embedded USB hosts behave right, and the /proc/acpi/wakeup
state isn't even vaguely integrated with the driver model wakeup stuff -- but
there are no known blocking issues there inside the USB stack or the main
host controller drivers.

- Dave



_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel