Re: Power Management plan for December - Meeting 2PM US ET 12/4 (today)
> Comments welcome. I'm not sure if there is a ticket about this, but when my recent-joyride G1G1 (which is plugged into AC) suspends, its screen goes to half-bright -- and stays that way forever. I don't know if this also happens with XOs which are not externally powered - but I think there ought to be a time-out such that eventually a 'suspended' XO turns its screen off completely. [A 'non-suspended' XO *does* eventually blank its screen.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Power Management plan for December - Meeting 2PM US ET 12/4 (today)
Hi Chris et al, We will have a one hour meeting from 2 - 3 PM US ET today (Thursday 12/4) to talk about power work for 9.1. Everyone who wants to contribute is welcome. We will use this dial in: From the United States 866-213-2185 From Outside the United States 1-609-454-9914 Code: 1671650 No IRC today. I want one round of old fashioned talking and writing on the whiteboard :-) I'll send out notes and we can do more IRC meetings in the future. Sorry for the short notice but call in if you can. Here is a proposed agenda: 10 minutes - confirm where we will document the requirements, specification and work plan. 10 minutes - layout the high level areas of work and assign engineering and QA lead for each. (one break of work is here: http://wiki.laptop.org/go/Feature_roadmap#Power_management) 30 minutes - review list of trac IDs (see below and URL above) targeted for inclusion. 10 minutes - assign action items and pick next meeting as needed. Thanks, Greg S * > http://lists.laptop.org/pipermail/devel/2008-November/021412.html Hi, This e-mail describes the work plan for power management during December. I've filed bugs for each item, so this plan is the list of bugs that should be fixed during December. Bugs I plan to fix: * #2765 -- Need to turn off DCON after some time in idle suspend * #3732 -- ARP broadcasts don't wake autosuspended laptops * #7981 -- EC mask setting is inefficient * #9055 -- Create 9.1 test plans for automatic power management Bugs I will need significant help to fix: * #6818 -- Make the multicast wakeup filter work with collaboration (Ricardo Carrano?) * #7958 -- DCON flicker on resume (kernel regression; perhaps Deepak, Andres, Mitch, or Adam Jackson?) * #9054 -- Speed up USB resume (kernel) It will take some effort to gather the resources for fixing the second list of bugs (and if anyone reading can help, I'd love to hear from you). However, if we are able to fix all of these bugs we'll be in excellent shape for having a shippable-by-default automatic suspend feature in 9.1, assuming serious bugs uncovered during testing can be fixed. The plan for January would largely involve following up with QA and looking for further cheap performance wins in suspend/resume. Comments welcome. Are there important power management bugs that I've left out? Thanks, - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management plan for December.
Hello! On Sat, Nov 29, 2008 at 2:51 PM, Michail Bletsas <[EMAIL PROTECTED]> wrote: > > > Chris Ball <[EMAIL PROTECTED]> wrote on 11/28/2008 04:18:11 PM: > > >> >> Bugs I plan to fix: >> >> * #2765 -- Need to turn off DCON after some time in idle suspend >> * #3732 -- ARP broadcasts don't wake autosuspended laptops > This works now and Ricardo has tested it. The remaining bugs in WOL don't > affect it. > B.t.w. this should be re-phrased as ARP requests for XO's own IP address. > > Ricardo, > > Can you update the trac? Sure. This has been tested in the past with good results. I am repeating the tests with the new improved signature wol filter and recent firmwares and will post results to the ticket (later today) > > >> * #7981 -- EC mask setting is inefficient >> * #9055 -- Create 9.1 test plans for automatic power management >> >> Bugs I will need significant help to fix: >> >> * #6818 -- Make the multicast wakeup filter work with collaboration >> (Ricardo Carrano?) > Again, WOL works as it is supposed to be. The WOL filter wakes up the laptop > when it receives a frame destined for a multicast address that the network > adapter listens for. That means that as we stand right now the XOs will wake > up on reception of every frame destined for the presence service. > One way out of this would be to stop the presence service before going to > sleep and starting it up again upon coming out of sleep. > In that manner presence updates won't wake up the XO, but traffic destined > to already running activities will. Chris, Yes, we've been testing this and "ethtool -s eth0 wol um" will do the trick (the current default is just "u", for unicast - no "m", for multicast). No need for signature based wol rules, here. Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management plan for December.
Chris Ball <[EMAIL PROTECTED]> wrote on 11/28/2008 04:18:11 PM: > > Bugs I plan to fix: > > * #2765 -- Need to turn off DCON after some time in idle suspend > * #3732 -- ARP broadcasts don't wake autosuspended laptops This works now and Ricardo has tested it. The remaining bugs in WOL don't affect it. B.t.w. this should be re-phrased as ARP requests for XO's own IP address. Ricardo, Can you update the trac? > * #7981 -- EC mask setting is inefficient > * #9055 -- Create 9.1 test plans for automatic power management > > Bugs I will need significant help to fix: > > * #6818 -- Make the multicast wakeup filter work with collaboration > (Ricardo Carrano?) Again, WOL works as it is supposed to be. The WOL filter wakes up the laptop when it receives a frame destined for a multicast address that the network adapter listens for. That means that as we stand right now the XOs will wake up on reception of every frame destined for the presence service. One way out of this would be to stop the presence service before going to sleep and starting it up again upon coming out of sleep. In that manner presence updates won't wake up the XO, but traffic destined to already running activities will. M.___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management plan for December.
Michael Stone wrote: > On Fri, Nov 28, 2008 at 04:18:11PM -0500, Chris Ball wrote: >> Comments welcome. Are there important power management bugs that I've >> left out? > > Yes; namely, finding or writing a good technical introduction to the > subject of power management as it applies to our software and hardware. > Such a document will be invaluable in coming months because, without it, > we'll communicate at a fraction of the efficiency we can achieve if > we're all starting from the same basic terminology and facts. > > Perhaps this document already exists and I just don't know about it? http://wiki.laptop.org/go/Power_management and its links at the top *should* be that document :-) Besides the technical details, there are 1. The requests from deployments for the feature: http://wiki.laptop.org/go/Feature_requests 2. The feature for tracking purposes, currently: http://wiki.laptop.org/go/Feature_roadmap#Power_management 3. The blueprint/plan to implement the feature; Mr. Ball's fine plan of attack belongs in this last one. Maybe http://wiki.laptop.org/go/Longer_battery_life that Kim Quirk created in October? I think Greg Smith's continuing work on 9.1.0 features and requirements will help organize this. -- =S Page ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management plan for December.
> ... if we are able to fix all of these bugs we'll be in excellent shape > for having a shippable-by-default automatic suspend feature in 9.1 Depends upon how inclusive a definition of "excellent" one chooses. [I'm the guy without wireless - I'm running wired ethernet.] A tremendous amount of progress has happened in the past year. To begin with, suspend would power off my ethernet (USB) adapter, and resume would not re-initialize it afterwards. That got fixed. Then, even with manually typing in 'ifconfig' commands, the XO might not see the LAN after suspend/resume. Network Manager 0.7 has improved things - now I can usually re-establish communication after suspend / resume by manually typing in the appropriate commands. From my perspective, two variables stand in the way of "excellent": (1) I do not understand which device/interface will be assigned by the XO to the USB ethernet adapter - it varies from install (build) to install, and from XO to XO. [If it is eth1, suspend/resume with NM 0.7 will often re-establish communication *automatically*; If it is eth0 (or eth2, which I've also seen), after suspend/resume NM 0.7 seems to establish IPv6 - I then have to manually stop the interface and reestablish it with an IPv4 address (to match my LAN).] [Upon booting, NM 0.7 likes to give my XO an IPv6 address (doesn't honor DHCP) -- but that is a separate problem, which I intend to ticket.] (2) Occasionally when setting up ethernet communications (either upon booting or following suspend/resume), even though all the kernel control blocks have the proper values in them, I get "unreachable" when I try to use the ethernet (I can ping myself, but not another system). I have so far not been able to discover what is not working correctly - my simplest "bypass" is to just reboot. [By the way, my ethernet connection suffers fewer setup failures when plugged directly into an USB port on the XO, than when plugged into a (powered) USB hub which is then plugged into the XO.] mikus p.s. I see that you are thinking about "speeding up" activating the USB ports upon resume. For myself, I do NOT have any complaint about the time currently being taken. I have to press something on the XO to wake it up - by the time I have transferred my hands back to my USB keyboard, it is usually ready to accept keystrokes. And by the time I finish entering a command, my USB ethernet adapter has also been initialized (though see above for software problems). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management plan for December.
On Nov 28 2008, at 16:18, Chris Ball was caught saying: > Hi, > > This e-mail describes the work plan for power management during December. > I've filed bugs for each item, so this plan is the list of bugs that > should be fixed during December. Thanks for putting this together. > Bugs I will need significant help to fix: > > * #6818 -- Make the multicast wakeup filter work with collaboration > (Ricardo Carrano?) > * #7958 -- DCON flicker on resume > (kernel regression; perhaps Deepak, Andres, Mitch, or Adam Jackson?) > * #9054 -- Speed up USB resume > (kernel) ... > Comments welcome. Are there important power management bugs that I've > left out? #7458 -- Intermittent timeouts during WOL suspend/resume stress. We need to solve this if we want to implement more aggressive suspend/resume. My suggestion for this one is to get Javier, Richard, and either myself or Andres in the same room so we can simultaneously trace the issue at kernel, network, EC, and WLAN firmware levels. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management plan for December.
On Fri, Nov 28, 2008 at 04:18:11PM -0500, Chris Ball wrote: >Comments welcome. Are there important power management bugs that I've >left out? Yes; namely, finding or writing a good technical introduction to the subject of power management as it applies to our software and hardware. Such a document will be invaluable in coming months because, without it, we'll communicate at a fraction of the efficiency we can achieve if we're all starting from the same basic terminology and facts. Perhaps this document already exists and I just don't know about it? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Power Management plan for December.
Hi, This e-mail describes the work plan for power management during December. I've filed bugs for each item, so this plan is the list of bugs that should be fixed during December. Bugs I plan to fix: * #2765 -- Need to turn off DCON after some time in idle suspend * #3732 -- ARP broadcasts don't wake autosuspended laptops * #7981 -- EC mask setting is inefficient * #9055 -- Create 9.1 test plans for automatic power management Bugs I will need significant help to fix: * #6818 -- Make the multicast wakeup filter work with collaboration (Ricardo Carrano?) * #7958 -- DCON flicker on resume (kernel regression; perhaps Deepak, Andres, Mitch, or Adam Jackson?) * #9054 -- Speed up USB resume (kernel) It will take some effort to gather the resources for fixing the second list of bugs (and if anyone reading can help, I'd love to hear from you). However, if we are able to fix all of these bugs we'll be in excellent shape for having a shippable-by-default automatic suspend feature in 9.1, assuming serious bugs uncovered during testing can be fixed. The plan for January would largely involve following up with QA and looking for further cheap performance wins in suspend/resume. Comments welcome. Are there important power management bugs that I've left out? Thanks, - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
