#8443 HIGH 8.2.0 (: Battery Percentage doesn't update until minutes after resume

[Zarro Boogs per Child]

#8443: Battery Percentage doesn't update until minutes after resume
-----------------------------------+----------------------------------------
   Reporter:  gnu                  |       Owner:  cjb                                         
       Type:  defect               |      Status:  new                                         
   Priority:  high                 |   Milestone:  8.2.0 (was Update.2)                        
  Component:  power manager (OHM)  |     Version:  Development build as of this date           
 Resolution:                       |    Keywords:  blocks-:8.2.0 polish:8.2.0 cjbfor8.2 relnote
Next_action:  design               |    Verified:  0                                           
  Blockedby:                       |    Blocking:                                              
-----------------------------------+----------------------------------------

Comment(by rsmith):

 Replying to [comment:10 mikus]:
 > Replying to [comment:9 rsmith]:
 > > Please do a discharge/recharge cycle while running olpc-pwr-log and
 send me the log files.  I you have idle-suspend enabled please turn it
 off.

 > I will not do that unless you give me a convincing explanation of what
 good it will do.

 It tells me what the EC thinks the SOC is and if its changing and
 operating in a sane manner. The logs you have pointed to though have
 enough info to tell me what I wanted to see.

 > As far as I am concerned, the current problem (percentage shown not
 changing) is that the tools (from batman.fth) that I used, had set the
 battery's eeprom to NOT invoke the periodic interrupt.  With the XO
 software to *recalculate* the charge percentage not being "started", the

 It doesn't work like that.  Batman simply re-initializes the values in the
 EEPROM to the factory defaults and none of the eeprom values control the
 1% SOC change ticks. For a Life battery 95% of the eeprom values are
 unused.

 The 1% SOC change tick delivery is controlled by a mask value that is set
 by the kernel.  If sugar fails to update the SOC then the most common
 cause so far has been a mask setting that has the ticks disabled.  If you
 enable loglevel 9 and do a kernel suspend/resume the logs will contain the
 commands that set that mask.  So we can see what its getting set to.  In
 many cases the suspend/resume fixes things.

 You can also plug and uplug external power. That generates power events
 which will cause sugar to try and update the battery status.  Restarting
 sugar should also set things to the proper value.  If you restart and then
 it never changes value after that then that further suggests that the
 SCI's are not happening.

-- 
Ticket URL: <http://dev.laptop.org/ticket/8443#comment:11>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system