Opened 4 years ago

Closed 4 years ago

#10369 closed defect (fixed)

Suspended XO-1 leaves CPU LED on after unplugging AC power

Reported by: hal.murray Owned by: pgf
Priority: normal Milestone: Not Triaged
Component: power manager (powerd) Version: 1.5/1.0 Software Build os852 aka 10.1.2
Keywords: Cc: rsmith
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

This may be tangled up with bug #10232.

I'm running a fake NTP server so I can monitor the clock over the net. The XO occasionally stops responding with the WiFi LED off.

If I wait for that to happen and then remove AC power, the CPU LED (lower right) doesn't go into blink mode when the system suspends.

I'm also running a program to monitor the battery. Since sleep doesn't work right when suspended, it sleeps for 1 second in a loop checking the time and adds another line to the log file every two minutes rounded up to the next wakeup. It shows more than two minutes between log lines so I'm pretty sure the system is actually suspended.

The log files contain two examples of this quirk.

comments.txt are my comments merged with some of the battery log lines.

The format of batstats:

First two columns are MJD and seconds-this-day in UTC (same format as ntpd log files).
3rd column is % of battery
4th column is battery voltage
5th column is battery current
6th column is system clock (seconds since epoch)

Attachments (5)

batstats (7.5 KB) - added by hal.murray 4 years ago.
comments.txt (3.0 KB) - added by hal.murray 4 years ago.
Merge of my comments with part of batstats
messages.txt (2.6 MB) - added by hal.murray 4 years ago.
/var/log/messages
powerd.trace (6.6 MB) - added by hal.murray 4 years ago.
wpa_supplicant.log (1.0 MB) - added by hal.murray 4 years ago.

Change History (14)

Changed 4 years ago by hal.murray

Changed 4 years ago by hal.murray

Merge of my comments with part of batstats

Changed 4 years ago by hal.murray

/var/log/messages

Changed 4 years ago by hal.murray

Changed 4 years ago by hal.murray

comment:1 Changed 4 years ago by pgf

  • Action Needed changed from never set to diagnose
  • Cc rsmith added

hal -- clearly the version field in this ticket is incorrect. could you fix that please?

could you also provide the output of "cat /ofw/ec-name", since this may be related to EC-firmare?

from the contents of the messages.txt and powerd.trace files, it's very clear that your system was suspending for over 600 seconds at a time, in the interval that you've commented "CPU LED has been on for a long time".

comment:2 Changed 4 years ago by hal.murray

  • Version changed from 1.0 Software Build 802 to 1.5/1.0 Software Build os852 aka 10.1.2

hal -- clearly the version field in this ticket is incorrect. could you fix that please?

Argh. Sorry.

comment:3 Changed 4 years ago by hal.murray

could you also provide the output of "cat /ofw/ec-name", since this may be related to EC-firmare?

Sorry I overlooked that request:

PQ2E35

comment:4 follow-up: Changed 4 years ago by hal.murray

I also see the same thing (CPU LED on rather than blinking) if I just wait long enough after the WiFi LED turns off.

I'll upload another full set of log files if anybody wants them. Here is a snippet from powerd.trace

: @ 1285324459 got wakeup: wlanpacket @ 1285324459, slept 48
: @ 1285324459 got event: fake_useractive, 1285324459, wlanpacket, , .
: @ 1285324470 got event: useridle1, 1285324470, , , .
: @ 1285324475 until-sleep_type is until_shutdown-soft
: @ 1285326117 got wakeup: wlanpacket @ 1285326117, slept 1641
: @ 1285326117 got event: fake_useractive, 1285326117, wlanpacket, , .
: @ 1285326127 got event: useridle1, 1285326127, , , .
: @ 1285326133 until-sleep_type is until_shutdown-soft
: @ 1285340536 got wakeup: rtcalarm @ 1285340536, slept 14402
: @ 1285340536 rtcalarm during until_shutdown
: @ 2010-09-24 08:02:16 found external power, sleeping instead of shutdown
: @ 1285340536 until-sleep_type is until_shutdown-soft
: @ 1285354940 got wakeup: rtcalarm @ 1285354940, slept 14403
: @ 1285354941 rtcalarm during until_shutdown
: @ 2010-09-24 12:02:21 found external power, sleeping instead of shutdown
: @ 1285354941 until-sleep_type is until_shutdown-soft
: @ 1285361955 got wakeup: keypress @ 1285361955, slept 7013
: @ 1285361955 got event: useractive, 1285361955, , , .
: @ 1285361955 got event: fake_useractive, 1285361955, keypress, , .

comment:5 in reply to: ↑ 4 Changed 4 years ago by rsmith

If you cut and past logs then you need the {{{ to keep trac from reformatting them.

> : @ 1285354941 until-sleep_type is until_shutdown-soft
> : @ 1285361955 got wakeup: keypress @ 1285361955, slept 7013
> : @ 1285361955 got event: useractive, 1285361955, , , .
> : @ 1285361955 got event: fake_useractive, 1285361955, keypress, , .

Is this the last message in the log? If so then the LED is doing exactly the right thing. You have not gone back to sleep.

comment:6 Changed 4 years ago by hal.murray

Sorry about the botched formatting. I noticed it, but don't know how to edit an existing entry and decided not to add to the clutter with a correction.

The log files are cleanly formatted.

The LED was on before I woke it up at the chunk of the log you quoted.
(I woke it up so I could grab the log files.)

Here is a simple way to tickle the probblem:

Turn on power saving.
Turn off WiFi.
Wait until it suspends.
Disconnect the AC power.  The system wakes up for the power change.
Wait a while.  The LED stays on.

comment:7 Changed 4 years ago by pgf

i've reproduced this. for me, on a fresh 852 install, with power management enabled, the power LED will stay on after the second suspend (when the laptop wakes to dim its screen).

this happens using both q2e45/pq2e35 (current) and q2e41/pq2e34 (shipped with 802), so it's not strictly an EC regression, but is presumably triggered by new power management behavior.

comment:8 Changed 4 years ago by pgf

richard -- fyi, this behavior doesn't happen using code from the top of the EC master branch.

comment:9 Changed 4 years ago by pgf

  • Action Needed changed from diagnose to no action
  • Resolution set to fixed
  • Status changed from new to closed

this was fixed some time ago.

it turns out the bug in the firmware was an old one, but it was being masked by kernel behavior.

workaround was applied in powerd, and is present in powerd-31 and later. (fix is a895220b8a7afe0fdbee02187d426233cb7a253c in the powerd repo.)

Note: See TracTickets for help on using tickets.