Release SuperZaxxon - Beta 3 released


Ran into stuff being slow after suspend again, opened CPU frequency application, dropped the CPU frequency by 1MHz -> everything went back to normal. So the clock frequency apparently is not being brought back up after suspend.
Yeah I can confirm that.
 
when I put my Pandora into low power mode, upon resuming my left nub no longer moves the mouse pointer, no problem with the right one though. I've tried going into the nub configurator and resetting the nubs through that, but it has no effect, have to reboot to get it working again!
 
Yup. At the cost of a little cpu usage to compress/decompress data in this reserved part of the ram.
 
Hi,


First, thanks for this upgrade, powersaving is a must!


The "Pandora input tester" application (from xfce "system" menu) does not work properly with kernel 3.2, but works well with 2.6.27 .


I've a black screen upon start up and I must press a key to see the virtual keyboard. Another quirk are the game keys that do not respond anymore. So DPad, A/B/X/Y, L/R, Start & Select keys are not hilighted when I press them .


I don't know if this is a kernel related issue but Super Geometry Dust does not start every time I execute it.


There is no problem when executing SGD the first time, from xfce menu, just after a fresh boot. But trying to start SGD a second time does absolutely nothing. I've tried to launch it with pnd_run and got the same result. Pnd_run does not print error message, nor dmesg.


There is no SGD issue under kernel 2.6.27.
 
Dear Notaz and EvilDragon!


I detected differing behavior of the state of PND games while Standby.


Some properly resume just where your left off, some have progress a little (less than real time) in the meantime, some have progressed equivalent to real time.


And also concerning the state in which the machine really gets depending on the running PND, differs! Traced this with dmesg!

Fact is: If the system detects a running PND, it goes not into standby, but rather only into Low Power Mode (which is also quite good concerning battery runtime, but Standby is about 4 times more efficient than Low Power mode, total runtime with Standby ~180


hours, with Low Power Mode 30-75 hours). Thus you first need to manually pause your game, then suspend, else your game runs on (in the Low Power Mode)!

The Low-Power mode has ALWAYS paused PNDs
This was definitely not 'ALWAYS' true for Low Power Mode in the past. In multiple games, after resume your game state has progressed far. Where I remember it certainly: Super Methane Brothers.


I did the standby test with Super Methane Brothers no under Beta 3, and it pauses/resumes correctly!


See a whole PND standby test series below.

and it sure does this on my unit (I've been playing PSX games all weekend long and were only taking breaks by directly going into low-power mode).
Glad to hear that, but I hope you understand my skepticism from the observations I made with the other PNDs.

Could it be somehow that Gianas Return uses the clock (or some other timer that continues to run) and updates itself once it starts up again?
The direction of your guess is the only plausible explanation if the Pandora was indeed in proper Standby and not only in Low Power Mode BUT nevertheless the game has progressed as much as real time happened. Maybe some games calculate everything which happened in that long execution pause at once on resume, (and drop quite many many thousand frames to catch up). But I don't know much about timing and game development. Info anyone?

Suspending with running PNDs works now!? Sort of...


Fact is: If the system detects a running PND, it goes not into standby, but rather only into Low Power Mode (which is also quite good concerning battery runtime, but Standby is about 4 times more efficient than Low Power mode, total runtime with Standby ~180 hours, with Low Power Mode 30-75 hours). Thus you first need to manually pause your game, then suspend, else your game runs on (in the Low Power Mode)!


Proof: Game "Giana's Return" running, game countdown at 140 seconds. Sliding power button to start standby. OP (seemingly) goes into standby. Power LED lights in less bright green (indicating standby). Waiting 60 seconds (with stop clock) then sliding power button again. OP resumes, screen goes on, "Giana's Return" is immediately responsive, counter at 79 seconds. Exactly 60 seconds, as in real time, have passed in the game! (The 1 seconds rounding error is just my finger/eye delay. 140 - 79 = 61 = 60 + 1)
I've just checked this, it does the unsafe suspend, and time passed is compensated on resume, otherwise it would confuse programs that try any kind of real time tracking. If you suspend for longer time with Giana, you'll see her death animation and only 1 life loss on resume, even if you suspend for 1 hour.

Checked dmesg, and it further proofs this.


For a real standby the Pandora logs:



Code:
Successfully put all powerdomains to target state.

For an attempted standby the Pandora logs:



Code:
Powerdomain (per_pwrdm) didn't enter state 1

Powerdomain (core_pwrdm) didn't enter state 1

Could not enter target state in pm_suspend

And then chooses Low Power Mode instead.
Seems to be unrelated bug, OMAP fails to suspend fully, perhaps because audio DMA is not drained.

The log file events are no coincidence, an unrelated bug unlikely.


All the power state success/failure messages correlate with my attempts to suspend/resume while having active PNDs!


See the chart below to learn the correlations, which I could always reproduce.


Standby test in various PND applications (via power slider)


Chart Format:


PND's Title


App resuming: Whether the running PND continued slow or fast and correct or with glitches.


Game State: Does it continue where you left off, or did the game "progress" while standby? (Whatever the technical reason is)


dmesg: Are there any time correlated power state messages in the system log file? (To ensure to not confuse it with the message from a more recent PND or Standby event, I always noted the last timestamp, to be sure that the next log message is really related to my PND / standby actions.)


MiniMenu idle


App resuming: Instantly without any glitches.


dmesg: Successfully put all powerdomains to target state.


Super Methane Brothers


Game State: Resumed properly (quickly moving opponents at same position as remembered).


App resuming: Instantly without any glitches.


dmesg: Could not enter target state in pm_suspend


GNU Jump


Game State: Game progressed, was already over on resume.


App resuming: Instantly without any glitches.


dmesg: The exceptional case: No log events for that time frame, neither confirming suspend success nor failure!


Hamster's Escape


Game State: Resumed properly (score, which normally quickly changes, was still same)


App resuming: Instantly without any glitches.


dmesg: Could not enter target state in pm_suspend


Primate Plunge


Game State: Game progressed, score 3 was suddenly 17 on resume, and game was over.


App resuming: Instantly without any glitches.


dmesg: Could not enter target state in pm_suspend


Retrobattle


Game State: Game progressed about 10 times slower than real time. Timer was at 195, suspended for 60 seconds, on resume timer continued at 188.


App resuming: Instantly without any glitches.


dmesg: Could not enter target state in pm_suspend


Super Geometry Dust


Game State: Could not resume after standby. Counter was at 10 secs, suspended. Tried to wake after 60 secs. Power slider has no effect. Crashed? Okay, seems that Super Geometry Dust has some troubles under Beta 3 now. Had to do a hard reset. Other topic.


Mr Drillux


Game State: Resumed properly (Quickly dropping air percentage (=timer) continued exactly, where it stopped).


App resuming: Instantly without any glitches.


dmesg: Could not enter target state in pm_suspend
 
Last edited by a moderator:
That's nice - but I'm not shure that even zram can compress the 200MB swap that my system uses after running FF for a couple of hours into 256MB RAM ;)
Don't just look at the swap used, also look at the buffers used. If you use 200MB of swap and 150MB of buffers, that means you really only exceeded RAM by 50MB which should easily be handled by zram.
 
The direction of your guess is the only plausible explanation if the Pandora was indeed in proper Standby and not only in Low Power Mode BUT nevertheless the game has progressed as much as real time happened. Maybe some games calculate everything which happened in that long execution pause at once on resume, (and drop quite many many thousand frames to catch up).
Yeah I think that's exactly what's going on, it all depends on how the games are coded to react to large time jumps.

Super Geometry Dust


Game State: Could not resume after standby. Counter was at 10 secs, suspended. Tried to wake after 60 secs. Power slider has no effect. Crashed? Okay, seems that Super Geometry Dust has some troubles under Beta 3 now. Had to do a hard reset. Other topic.
Sounds like a problem with SGX driver, I already know it can't suspend properly while 3D is active, not much can be done here because it's a closed blob for the most part.
 
Last edited by a moderator:
Does it send a SIGSTP or a SIGSTOP when suspending? Might be a good idea to come up with a standard "time to go to sleep now" procedure that applications need to follow if they're to suspend nicely. Most applications will not need it, suspending is no problem, but apparently a few do, either to reset their timers on continue or unload their 3D somehow (or exit cleanly because they know they can't be resumed anyway)
 
@WizardStan: Yes, application standards (or better: recommendations) for how to handle sleep/resume/clock/etc signals would be a fine thing, but voluntary (recommendation!) as not all PND devs will implement it as the OpenPandora spirit is freedom and not restriction and bureaucracy! "Apps which comply, get the optimum, apps which don't, still work somehow and the OS remains stable at least."


@notaz: Am curious to get your assessment of the "Standby test in various PND applications" with the attached dmesg log.
 
Last edited by a moderator:
I have the beta 3 up since a few days on my rebirth Pandora (512 MB).


Settings I've changed: max. OP 5, max clock 1050. But I let the Pandora most times run @600 MHz.


No special program that runs as background task.


My problem ist, that the kernel 3.2 freezed my pandora.


If I let suspend the device, it sometimes don't wake up. Even if I start the OS and do nothing, the device freezed after a few minutes.


I need some ideas, how I can sort out the problem and maybe can give better feedback of the problem.


The frezzes don't happen with the old kernel.
 
I noticed i can't boot anymore my old zaxxon (the release before Super) SD card with my two OP flashed with SZB3.


Tried many times.
 
@Notaz: Am curious to get your assessment of the "Standby test in various PND applications" with the attached dmesg log.
Not much, except that most of things you tested fail to suspend properly, I'm guessing it's related to sound, no ideas how to fix that at the moment.

My problem ist, that the kernel 3.2 freezed my pandora.


If I let suspend the device, it sometimes don't wake up. Even if I start the OS and do nothing, the device freezed after a few minutes.


I need some ideas, how I can sort out the problem and maybe can give better feedback of the problem.


The frezzes don't happen with the old kernel.
If the device freezes there is not much you can get out of it, so I can only guess what's wrong. Maybe you flashed older firmware and did not fully flash SZ beta3 after that?

I noticed i can't boot anymore my old zaxxon (the release before Super) SD card with my two OP flashed with SZB3.


Tried many times.
Need more details about what's happening.
 
The device did come with SZ beta1. I've flashed beta2 that runs fine under the old kernel since about 3 weeks. I must say, that I didn't test the 3.2 kernel before.


I do some test without any SD Card, to sort out an incompatible card. Have one Sandisc Extreme 32 GB in Slot 1 and a Transcend 8 Gb MicroSD HC class 6 in Slot 2.


Since noone semms to have problems like me, this or a bad flash is most likely the problem, I hope.


edit:


The cards are not the problem. I've let the Pandora run with WLan on for about 10 minutes. The clock shows the correct time, so the system was OK. Than the WLan LED did switch off. That was the point the system frezzed.


edit 2:


Yes, exact 10 minutes. That is the time, the device should switch off the screen, right ?


edit 3: Next reboot, test without WLan. The device is alive after 10 minutes, but the power savings didn't switch off the LCD. So I switch on WLan without reboot. The device was on for about 20 minutes.


Next test after reboot. WLan on. Freeze after 10 minutes again.


It must have to do with the power saving settings.
 
Last edited by a moderator:
I reinstalled the Zaxxon HF7b1 (to be par with the SD system), and now it doesn't boot at all with the SD card inserted.


When i hold R and select default boot, have a file not found /lib/uImage and some stuff after that, so i presume there's not bootloader update in HF7b1.


Is there a preferred downgrade to test ?


Maybe my card is corrupted, but it's highly unlikely because i used it a lot, and used it just before upgrading to SZb3.
 
Ok, i confirm it's a bug.


I reflashed with SZb1, and i successfully booted my HF7b1 card.
 
Back
Top