Suspending (closing lid), CPU heats up, locks up


ible

ible

professional vim user
Joined
Mar 24, 2014
Messages
2,591
Location
Seattle, WA
i've had this happen a couple times. i'll shut the pyra lid for a while, come back (30 minutes or more later), and the device feels really hot (even hotter than when in use), and it's unresponsive. the screen is off, and an LED on the power button is active, but that's the only sign of life. i have to hold the power button for 10s to shut down the unit.

/var/log/syslog doesn't show anything particularly inspiring:
Code: 
Mar 18 19:19:53 localhost systemd[1]: Started Session 6 of user ible.
Mar 18 19:20:58 localhost kernel: [ 2337.937162] [UFW BLOCK] IN=wlan0 OUT= MAC=ASDF SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=50288 PROTO=2
Mar 18 19:21:09 localhost kernel: [ 2349.016557] dmtimer posted=0
Mar 18 19:21:59 localhost kernel: [ 2398.126889] DSI: omapdss DSI error: VC(0) busy when trying to configure it!
Mar 18 19:21:59 localhost kernel: [ 2398.134309] DSI: omapdss DSI error: VC(1) busy when trying to configure it!
Mar 18 19:21:59 localhost kernel: [ 2398.141934] DSI: omapdss DSI error: VC(2) busy when trying to configure it!
Mar 18 19:21:59 localhost kernel: [ 2398.149288] DSI: omapdss DSI error: VC(3) busy when trying to configure it!
Mar 18 19:21:59 localhost kernel: [ 2398.342923] dmtimer posted=0
Mar 18 19:23:03 localhost kernel: [ 2462.830785] [UFW BLOCK] IN=wlan0 OUT= MAC=ASDF SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=50296 PROTO=2
Mar 18 19:25:08 localhost kernel: [ 2587.826957] [UFW BLOCK] IN=wlan0 OUT= MAC=ASDF SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=50304 PROTO=2
Mar 18 19:26:22 localhost kernel: [ 2661.189166] dmtimer posted=0
Mar 18 19:26:24 localhost systemd[1]: session-4.scope: Succeeded.
Mar 18 19:26:25 localhost systemd[1]: session-6.scope: Succeeded.
Mar 18 19:27:13 localhost kernel: [ 2712.822263] [UFW BLOCK] IN=wlan0 OUT= MAC=ASDF SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=50312 PROTO=2
Mar 18 19:29:18 localhost kernel: [ 2837.714370] [UFW BLOCK] IN=wlan0 OUT= MAC=ASDF SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=50320 PROTO=2
Mar 18 19:30:01 localhost CRON[10412]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Mar 18 19:31:23 localhost kernel: [ 2962.710995] [UFW BLOCK] IN=wlan0 OUT= MAC=ASDF SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=50328 PROTO=2

[nothing really around when i have to shut it down.  the next line is me booting again]

Mar 18 20:10:51 localhost kernel: [    0.000000] Booting Linux on physical CPU 0x0
 
Last edited:
I've had that happen occasionally too. It also happens when I'm using it. Often clicking on something will trigger the freeze.
 
Guaranteed to lock up if left to idle, same behaviour regardless of reflash to emmc or sd card.
 
Mine oddly doesn't do it that often. It's only done it twice I think while idling in my pocket.
 
Exactly, maybe something in cron, or a loop from the commandline:

Code: 
while :;do top|head -10 >>debug.log;sleep 55;done

Note that the machine gets out of idle sleep if you touch it, so don't touch any keys until you see it die.
Also take a flashlight and shine on the display (or watch the Pyra's display with an angle in sunlight). It could also be that the video background light does not come up, but the system is fine; so maybe you still see your display faintly.
 
You can't use top like that, it's an interactive app designed to run until you press q or exit it some other way. You probably want to use ps instead, something like:
Code: 
while true; do echo --- >> logfile; ps -ef --sort pcpu|tail -n 10 >> logfile; sleep 60; done

Note I tried to tidy up ps's output and include the pcpu value (instead of cumulative time) but as soon as I add a -o flag it goes into tree mode. Dunno what's up with that.
 
levi said:
You can't use top like that
Click to expand...
Yes you can; at least, it works on my Debian. Now it can be the Pyra (ARM Debian) has another implementation of top, so I can not be 100% sure; don't have a Pyra yet.
There is room for improvement, by adding "-b" you wont lose your cursor due to the control characters printed in the log file, so:

Code: 
while :;do top -b|head -10 >>debug.log;sleep 55;done

At although the last line is of course, the last line it wrote before freezing, and the logfile timedate has the date of the last write action; top itself also writes the time, so you can also look in the file itself, after rebooting the frozen Pyra.
 
Well it goes into interactive mode in Arch. I've no idea how it detects nor why exactly it does in debian. You'll note I emitted a --- into the log file to separate out each 10 line block.
 
top is same in both arch and debian. With -b option, top starts in non-interactive batch-mode.
Code: 
-b  :Batch-mode operation
            Starts top in Batch mode, which could be useful for sending output from top to other programs or to a file.  In this mode, top will not accept input and runs
            until the iterations limit you've set with the `-n' command-line option or until killed.
-n  :Number-of-iterations limit as:  -n number
            Specifies the maximum number of iterations, or frames, top should produce before ending.
from "man top"

Therefor
Code: 
top -b -n 1
is similar to ps
 
Yes, the -n option made it return after it completed that number of iterations. Without it, it wouldn't return to the terminal, just sleep for a few seconds and then print out the table again, and then if you kill it the system then waits for 55 seconds in @FBnil's script.
 
i wanted to rule out the CPU, so i forced the pyra from going into the lowest 250MHz state (cpufreq-utils i think), keeping it at 500MHz. but that didn't help.

i'll try the top command logging the next time i'm feeling lucky :D
 
We disabled suspend because there's a driver causing something like that... but I didn't have that issue in idle mode yet.

It does not disable the keyboard backlight atm, so that heats up the display when you close the lid. I always switch off the keyboard backlight before closing the lid.
 
Ok, so when you have to leave the Pyra just a few minutes, you can just shutdown the Keyboard Light, and close the Lid, but when you want to put in your pocket, its better to shutdown the Unit..
 
Refitting shouldn't do anything. The CPU is soldered onto the CPU board.
Nothing you can fix yourself.

Would be interesting to find out what happens here. Most of the freezes I had were when the battery ran too low. Oh, and I think there's still one bug where the system can freeze when the battery is full and the charger stops charging.

Did you have a charger connected?
 
EvilDragon said:
Refitting shouldn't do anything. The CPU is soldered onto the CPU board.
Nothing you can fix yourself.

Would be interesting to find out what happens here. Most of the freezes I had were when the battery ran too low. Oh, and I think there's still one bug where the system can freeze when the battery is full and the charger stops charging.

Did you have a charger connected?
Click to expand...
I though more about the contact between the CPU and the Mainboard.
But no socketed CPU on a mobile device?
Have you no shame? ;)
 
You must log in or register to reply here.

Similar threads

M
Nochmal USB NET
Replies
1
Views
894
manni
M
Back
Top