Release 3.2 kernel issue tracking thread


Well, it seems to have frozen for me as well when I closed the lid for a while, so there IS some issue still left here.


However, the battery-empty LED was still blinking, so the system wasn't dead... but the screen was black and never came back to life (except for a hard reboot).


I wonder what that could be.
 
Well, it seems to have frozen for me as well when I closed the lid for a while, so there IS some issue still left here.
The one time this happened to me, I had conveniently left dropbear running. ssh'd in and found Firefox chewing up 100% CPU. Killing it did not cause the screen to restore though so I had to reset anyway. In retrospect, I should have tried closing and opening the lid after killing firefox, but I didn't think of that.
 
I made a pause from playing a game using FBA.


Unpausing didn't do anything, so I'm pretty sure FBA has crashed as well.


Maybe some apps don't like switching the screen off with the new kernel?
 
EDIT: I'm thinking that this might have something to do with this: http://git.openpando...118c9a053c479a5 . So I added "echo 0 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout" to my btup script, and now I'm just seeing if this happens again.
It's a shame if that doesn't work, BT chip has full flow control connected and should be able to wake the OMAP when needed without data loss by asserting CTS/RTS. Maybe it needs tcgetattr() call, setting CRTSCTS flag to enable flow control, and then tcsetattr() (would be good to first check if CRTSCTS is set by default).
So, did it happen without sleep_timeout?


I've found you can set ctsrts with stty, and it's already set for ttyO0 by default.
 
After 60 hours in standby, my battery is down just 29%. Round it out to an even 30%, say 0.5% per hour, and you're looking at a solid 8.3 days of downtime. This means that if you are in the middle of something and your battery starts flashing critical at 5%, you can pop it into standby and still have an estimated 10 hours to find an outlet. There are no ends to the wonders that the great and powerful Notaz can pull off.
 
Clarke's third law seems relevant here...
 
Last edited by a moderator:
I can translate some of it:

  • updated to 3.2.14 (from 3.2.1)
  • maybe fixed the charger LED
  • overvolting should be working
  • added RAM overclock ability (highly experimental)
  • attempt to deal with SD erratum better
  • re-added composite/svideo switch for TV out


It's all ready for ED to do beta3 when he finds time.
 
Last edited by a moderator:
Happens some times: Running Panorama, selected PND for download, download completed, but while writing to SD, the system froze.


The other times installing games worked normal, but already 2-3 times I experienced this system freeze.
 
OpenPandora - Battery runtime study under the new experimental kernel 3.2.1 (as promised)


HW: OpenPandora 1 with a 4000mAh battery pack


OS: SuperZaxxon, Release 1.5 Beta 2 with Kernel 3.2.1


STUDY CONDUCTED: 28-Mar - 04-Apr-2012


ABBREVIATIONS: LPM = Low Power Mode; SBY = Standby Mode; MinM, MM = MiniMenu


STANDBY:


Runtime | Power drop per hour | Condition


200h, 0.50 %/h -- Optimum


180h, 0.56 %/h -- Average


160h, 0.63 %/h -- Minimum


LOW POWER MODE:


Runtime | Power drop per hour | Usage


75h, 1.33 %/h -- Minimal use: No Screen, no WiFi, idle system


45h, 2.25 %/h -- Average use: Idle app with screen or busy app w/o screen, no WiFi


30h, 3.33 %/h -- Intensive use: App, Screen, WiFi


Detailed log and calculations here:

Code:
-- TESTING IN XFCE

-- Time	 Battery Prediction Activity/Remark

-- 20120328-0130 93% 40:30 Audacious MP3 playback in XFCE + sound through headphones + lid closed

-- 20120328-1540 85% 165:27 Awake from Standby in XFCE

-- 20120328-1600 84% 169:16 Resume from low power mode, GNOME Terminal open and idle in XFCE, going into low power

-- 20120328-1949 82% 120:16 Resume from low power mode in XFCE

-- 20120328-2039 81% 147:09 Resume from standby in XFCE

-- 20120328-2225 80% 145:09 Resume from low power mode in XFCE

-- 20120329-0005 77% 140:09 Resume from low power mode in XFCE

-- 20120329-1214 70% 127:46 Resume from low power mode in XFCE

-- 20120330-0045 65% 12:22 Playing "Color Lines" in XFCE, turn based game, idle, closing lid to low power mode

-- 20120330-1550 56% 09:30 Resume from low power mode in XFCE, play for about 10 seconds, quit, long enough that the prediction already factored in that use.

-- 20120330-1555 56% 17:19 Idle on XFCE Desktop

-- 20120330-1602 ??% ??:?? Playing "Frogatto" in XFCE, game busy (not paused), closing lid, opening, see fullscreen CLI for about 0.25 secs, than game screen, but frozen, trying all kind of keystrokes, no reaction, assuming total system freeze, hard reset.

-- 20120330-1621 55% ??:?? Playing "Giana's Return" in XFCE (app required 600mhz and I granted it to it), game busy not paused (150secs remaining level time), closing lid

-- 20120330-1628 54% 08:18 Resumed. Game counter reached 0 secs meanwhile, character died, its sprite is in the process of falling off the screen (jump n run animation style), very slowly (about 1-2px per second) when I open the lid, but after 2-3 seconds the normal CPU operation seems to continue, and the sprite fell of very smoothly (normal).

-- 20120330-1628 54% 16:37 Idle on XFCE Desktop

-- 20120330-1628 54% ??:?? Playing "Giana's Return" in XFCE (at 600mhz), pausing game, closing lid

-- 20120330-2032 51% 11:09 Resuming, "Giana's return" runs slow for about 20secs, then normal again, quitting

-- 20120330-2038 51% 15:45 Idle on XFCE Desktop


-- TESTING IN MINI MENU

-- Time	 Battery Activity/Remark

-- 20120401-0200 63% Idle in MiniMenu, closing lid

-- 20120401-0915 53% Resume from low power mode in MiniMenu

-- 20120401-1027 50% Idle in MiniMenu, closing lid

-- 20120401-1637 42% Resume from low power mode in MiniMenu

-- Charging.

-- 20120401-2209 99% Playing "Transdimensional Hellspider", pausing game, closing lid

-- 20120402-1144 65% Resume, "Transdimensional Hellspider" immediately fully responsive

-- Irrelevant events.

-- 20120403-0245 60% Playing "GTA" in "PCSX" at 700 Mhz, pausing game through PS1 menu, PCSX overlay shows 23% CPU usage, closing lid.

-- 20120403-1045 35% Resuming, "GTA" immediately responsive, game in main menu or demo mode, sliding power button to standby

-- 20120404-0025 27% Resuming, "GTA" plays at low FPS, back to normal after about 20secs

-- Device off.

-- 20120404-0142 26% Playing "GTA" in "PCSX" at 700 Mhz, pausing emulation, sliding power button to standby

-- 20120404-1528 18-17% Resume, continuing emulation, "GTA" plays at low FPS, back to normal after about 20secs



-- CALCULATIONS FOR STANDBY --


-- Prediction at 85% batt is 165:27, for 100% this means what runtime?

165.5/0.85:194.706

-- Prediction at 81% batt is 147:09, for 100% this means what runtime?

147.15/0.81:181.667

-- Real measured batt loss while standby for 14 hours is 8%, for 100% this means what runtime?

14/0.08:175.000

-- But as the percentage is given without decimal points, it varies between

14/0.07:200.000

14/0.09:155.556

-- The truth will be somewhere here:

(194.71+181.67+175.00)/3:183.793

-- Lets say between 160-200 hours standby runtime


-- Some more calculations, also prove the range 160-200h. Format:

--- Name of the activity

--- Prediction in hours / current percentage = Predicted runtime for 100%

--- Runtime in hours / percentage drop = Calculated runtime for 100%

--- Percentage drop / runtime in hours = Percentage drop per hour


--Standby with "GNOME Terminal" in XFCE

120.25/0.82:146.646

3.85/0.02:192.500

1/#:0.005


--Standby with XFCE idle

145.15/0.80:181.438

1.75/0.01:175.000

1/#:0.006


--Standby with XFCE idle

140.09/0.77:181.935

1.70/0.03:56.667

1/#:0.018--Measured drop seems far off. Why? Possibly it was in LowPowerMode and not StandBy?


--Standby in idle XFCE

127.75/0.70:182.500

12.15/0.07:173.571

1/#:0.006


--Standby with "Color Lines" turn based idle game in XFCE

9.5/0.56:16.964-- Low runtime prediction, as this already factored in some secs of app usage after wakeup

15/0.09:166.667

1/#:0.006


-- Standby with "PCSX" emulating "GTA" in main menu

-- No prediction in MiniMenu

13.7/0.08:171.250

#/1:171.250


-- Standby with "PCSX" with paused emulation of "GTA"

-- No prediction in MiniMenu

13.75/0.088:156.250

#/1:156.250


-- SUMMARY FOR STANDBY:

-- Runtime: ~ 180 (160-200) hours.

-- Drop per hour: 0.5 - 0.625 %.

100/160:0.625-- min

100/180:0.556-- avg

100/200:0.500-- max



-- CALCULATIONS FOR LOW POWER MODE --


--- Name of the activity

--- Runtime in hours / percentage drop = Calculated runtime for 100%

--- Percentage drop / runtime in hours = Percentage drop per hour


-- MiniMenu idle

7.25/0.10:72.500

1/#:0.014


-- MiniMenu idle

6.15/0.08:76.875

1/#:0.013


-- "Transdimensional Hellspider" paused

12.7/(0.99-0.65):37.353

(0.99-0.65)/12.7:0.027


-- Ingame paused "GTA" in "PCSX" at 700 Mhz (used: 23%)

8/0.25:32.000

1/#:0.031



-- SUMMARY FOR LOW POWER MODE:

-- Runtime: ~ 45 (30-75) hours.

-- Drop per hour: 1.3 - 3.3 %.

100/30:3.333-- app, WiFi

100/45:2.222-- quite idle app, no WiFi

100/75:1.333-- no Screen, no WiFi, idle system



-- OBSERVATION FROM OTHER PANDORA USERS


-- EvilDragon claims standby consumes 10% battery per 24h

24*10:240.000-- Means total runtime of X hours

100/240:0.417-- Means drop of X %/h

--My observations showed a total runtime between 160-200 h.

-- Assuming 180h total runtime, this means a drop of X %/h

100/180:0.556



-- WizardStan: Under the new kernel, idle with wifi and screen off sees a drop of about 2% per hour, full suspend sees a drop of about 0.5% per hour: approximately 4 times the battery life when suspended than when simply idle.


100/2:50.000

100/0.5:200.000


Bear in mind, that my calculations are based on certain assumptions, from certain observations:


To determine whether my Pandora is in SBY or LPM, I considered:

  • While operation:
    SBY: Power LED in dim green
  • LPM: Power LED in strong green
[*]Post operation:

  • SBY: The system log, accessed via "dmesg", shows a lot of traces of the SBY
  • LPM: The system log shows no traces of LPM




What is triggering LPM / SBY ?


XFCE:

  • LPM: Being idle for a certain time.
  • SBY: Power Slider, Closing the lid (although Lid-Close-Settings claims that this action causes LPM, obviously not true!)


MiniMenu:

  • LPM: Closing the lid or being idle for a certain time.
  • SBY: Power Slider
 
Last edited by a moderator:
Did you re-downloaded and re-flashed ?


May sounds a bit heavy, but it's necessary to be 100% accurate.


What was your battery level ?


Pandora button + power button didn't rebooted ?

The battery level was about 50%, but doesn't matter. The problem exists with all battery levels from near full to near empty.


The Pandora + Power worked. I forgot this combination, sorry.


Ok, I think the problem is the "going to low power mode" lid setting.


What I did:


- tar $HOME


- reflash


- tested: all works fine.


- untarred old home


- freezes.


- back to "fresh" home


- all good again.


- removed applets: cpuspeed, brightness, volume


- all ok


- added my private wlan config


- all ok


- set the lid option to "lower power mode when lid closed"


- freeze


- set the lid option to "black screen when lid closed"


- all ok again.


So there's some kind of problem.


What exactly did that option? Is it a running daemon or event which gets irritated when going to low power mode?


greetings,


sirtobi


P.S.: Worse checking, have to wait 12 Minutes between all actions ;-)
 
Dont know whether this is a known issue:


I wasn't able to make a ext2 and Linux-Swap Partition on my 32 GB SD-card. When usind the old Kernel everything was fine.


Here's the output from Gparted:


(It's Fat 32 here but the output was the same)

GParted 0.6.4


Libparted 1.8.0


Format /dev/mmcblk1p1 as fat32 00:00:02 ( ERROR ) calibrate /dev/mmcblk1p1 00:00:00 ( SUCCESS ) path: /dev/mmcblk1p1


start: 8192



end: 61448191



size: 61440000 (29.30 GiB)
set partition type on /dev/mmcblk1p1 00:00:02 ( ERROR ) libparted messages ( INFO ) Error informing the kernel about modifications to partition /dev/mmcblk1p1 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/mmcblk1p1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. The kernel was unable to re-read the partition table on /dev/mmcblk1 (Device or resource busy). This means Linux won't know anything about the modifications you made until you reboot. You should reboot your computer before doing anything with /dev/mmcblk1. Error informing the kernel about modifications to partition /dev/mmcblk1p1 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/mmcblk1p1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. The kernel was unable to re-read the partition table on /dev/mmcblk1 (Device or resource busy). This means Linux won't know anything about the modifications you made until you reboot. You should reboot your computer before doing anything with /dev/mmcblk1.
 
Last edited by a moderator:
How do active PNDs behave after resuming from standby under kernel 3.2.1?


Fact (by notaz): If SuperZaxxon, Release 1.5, Beta 2, with kernel 3.2.1 goes into standby, it unmounts the SD cards.


From my observations: This has different outcomes for running PNDs:

  • Most: Partial crash or complete system crash.
  • Some: You can resume, but you are in trouble: After resume you arrive at a CLI full screen, but via ALT-CTRL-F7 (corresponding to the Pandora keys: Start-Select-Fn-6) you get back to GUI mode.
    In some PNDs you can continue without problems (ie: PenguPop), some crash.
  • But as soon as you return to your launching environment (XFCE desktop / MiniMenu), the system seems quite broken (ie: MiniMenu shows only few apps, also rescan does not help. Indication that only the NAND PNDs show up, and the SDs are not accessible anymore).
[*]Few: Only minor problems. A bit unresponsive for about 20secs after resuming ("catch up"), but then continuing at normal speed and without loss of state/data. Examples:

  • Pencil with unsaved drawing.
  • PCSX with running or paused emulation.
  • Audacious aborts currently played audio file because of I/O error, but as soon as you trigger a new track, or the current one again, it plays back normally.
 
Ok, I want to have a long idle time and so I tested SuperZaxxon with Kernel 3 but without luck.


Whenever the Pandora gets idle, it hangs.


I have tried the minimal case:


- no sd cards


- no usb


- no wlan


- just booted kernel 3 with xfce


- started top


- started an while/dmesg|tailloop


- waited


- freezed pandora


The last I could see in top was 100 processes in sleep staed and 1 running. 12 Minutes uptime.


When the Pandora hangs no key has any effect, tried to switch to console, power button, Pandora-Button. I have to remove battery to get it going again.


Any ideas on how to debug this?


greetings,


sirtobi
sounds like problem I have too; I can also freeze the system by advancing the time (makes sense) - no idea how to fix it, a work around is to disable the automatic LCD blanking (at least this works for me to prevent the idel freeze).
 
I have an issue to report. There is too much money in my paypal account. I desperately need to offload some of this money. Where should I send it?
 
I just compiled this new 3.2.14 kernel under Slackware.


I confirm the SD card access is way faster. Picodrive loads roms instantly.


I also noticed a bug: i run a rom, i let the screen goes off with the powersaving, then when i bring it on, the graphic are jerky. The sound stays ok.


I will release it with my new -current build probably tomorrow.
 
I have an issue to report. There is too much money in my paypal account. I desperately need to offload some of this money. Where should I send it?
Rebirth Competition Fund is still open for donations

About the price pot: Good idea :)


You can send money via PayPal to "donation@openpandora.org" and put "Pandora Rebirth Competition" as comment.


I'll throw that money into the price pot then.


Please include your nick in the comments as well if you want to be mentioned as donor :)
 
Back
Top