Release SuperZaxxon Final released!

[Linux-SWAT]

Maybe record the logs on the NAND instead of the ram ?


Something like that:

mkdir /home/log

rsync -a /var/volatile/log /home/log

mount --bind /home/log /var/volatile/log

/etc/init.d/syslog restart

or

/etc/init.d/syslog-ng restart

 

[WizardStan]

I'm out of ideas at the moment. It's all rather unfortunate as the whole system dies and there is no way to save a log or anything.

Is it really, truly, completely frozen? Or is it just not responding? What if someone were logged in via ssh?

 

[FaeMinx]

When my screen started blanking normally yesterday I wondered if my issue had somehow dissapeared... But alas, even something as simple as listening to music via Audacious even at default MHz causes it to freeze after 10min.


So yes, the system is completely unresponsive and the music just stops too - so I assume it really has completely frozen?


Could it have anything to do with accessing data while it tries to go into low power mode?


I don't think it's the Free e-Book Reader as it's not the only program that causes this. But anyway; it's version 0.1.10.0 and PNDstore doesn't list it. I got it aaaaaages ago, I'm not sure where.

Maybe record the logs on the NAND instead of the ram ?

Something like that:

mkdir /home/log

rsync -a /var/volatile/log /home/log

mount --bind /home/log /var/volatile/log

/etc/init.d/syslog restart

or

/etc/init.d/syslog-ng restart

Should I go ahead and do this? And do I type it in the terminal just like this? Then what?


Sent from my HTC Sensation Z710e using Tapatalk 2

 

[Linux-SWAT]

Better wait for Notaz to comment.


Don't remember if you already answered this, but does the freeze happens under 2.6.x kernel ?

 

[FaeMinx]

Better wait for Notaz to comment.

Don't remember if you already answered this, but does the freeze happens under 2.6.x kernel ?

Initial test seems to show that it doesn't...


Sent from my HTC Sensation Z710e using Tapatalk 2

 

[notaz]

Is it really, truly, completely frozen? Or is it just not responding? What if someone were logged in via ssh?

Other reporters say it's completely dead, not even ping responds.

Should I go ahead and do this? And do I type it in the terminal just like this? Then what?

I doubt it would help.


Random question: did you change lid-close settings, like make it suspend on lid close or something?

 

[FaeMinx]

I did actually.


"Go into low power mode (same as when pressing the power button for less than 3 seconds)"


Strange that would be the problem... As when I did close the lid there didn't seem to be an issue except for getting disconnected from my phone each time. The freeze only seemed to happen when I left the lid open.


I'm going to boot back into kernel 3.2 and change that option to "turn off screen" instead and see if it makes any difference.

 

[superatarian]

Well I upgraded and even install the OS on a SD card. Everything went very well and everything works fine. I have yet to experience my screen blanking out and charging seems to be going well. I did notice that when I set the lid closing parameters to go into low power modem, that it also disabled the USB host. That is different. I am satisfied. Thanks ED.....

 

[FaeMinx]

Sorry it's taken me so long to get back to this - I had a lot to do yesterday.


Anyway, there is definitely a feature bug that *could* be what's causing some people's Pandoras to hang:


With changing the lid close setting back to "turn screen off" everything behaved normally - the screen would blank at 10min but music would still be playing and the system didn't freeze.


Changing the setting back to "go into low power mode" meant that at 10min the screen would blank and the music would stop. (i.e. it was in low power mode).


However, in the few tests I've done this morning I haven't gotten my system to hang again yet - perhaps by me playing with this setting something has come 'unstuck' and now my Pandora is behaving like most others?


Anyway - I'm sure it shouldn't be doing that: going into low power mode when the screen blanks. It should only do that when the lid closes... So for some reason it's interpreting screen blanking as the lid closing.


If you could disassociate these two settings then perhaps the small percentage of people experiencing hangs won't anymore?


If possible we should find out if the other people who are experiencing this issue had aslo set the lid close setting to "go into low power mode".


So far my system is now apparently normal so unless you have ideas for something you want me to check I don't know what else I can do to help here.


If I do manage to get my system to hang again I'll report here immediately, but I have a feeling it's not...


Sent from my HTC Sensation Z710e using Tapatalk 2

 

[notaz]

Anyway - I'm sure it shouldn't be doing that: going into low power mode when the screen blanks. It should only do that when the lid closes... So for some reason it's interpreting screen blanking as the lid closing.

Yeah there is a bug in the scripts, for which I've pushed patches to GIT. Hopefully that'll resolve it, thanks for testing!

 

[FaeMinx]

Anyway - I'm sure it shouldn't be doing that: going into low power mode when the screen blanks. It should only do that when the lid closes... So for some reason it's interpreting screen blanking as the lid closing.

Yeah there is a bug in the scripts, for which I've pushed patches to GIT. Hopefully that'll resolve it, thanks for testing!

No problem.


Sent from my HTC Sensation Z710e using Tapatalk 2

 

[Zink]

I'me getting the old kernel issue again:

With the SZ Final I can't boot into the old kernel any more (it doesn't seem to be a bug, because someone else would have reported it earlier). When booting the progress bar goes to the end, then screen blacks, and a few seconds later the message box (graphical mode) appears: "Unable to contact settings server. /usr/bin/dbus-launch terminated abnormally with the following error: EOF in dbus-launch reading address from bus daemon". And then I cannot do anything besides hard reset, because touch screen, keyboard and nubs don't work. I have installed SZ Final by flashing over the SZ beta 5.

Notaz suggested that I forgot a file while flashing, so I reflashed and that helped for one or two runs. But two days ago I tried to boot the old kernel again, and I got the same message again. So now it cannot be caused by bad flashing. Any ideas?


Actually I need the old kernel for Audacity only, and only for recording. So maybe there is another program that can record sound from line in with a live signal level gauge? I haven't found anything in the repo, and yes, I know about arecord, but I really need the gauge.

 

[porg]

Charging: I already reported and reported.


In the meantime I observed 2 full charging cycles, and again I noticed that my Pandora (CC, 256MB) under Pandora OS SuperZaxxon Final (1.5), does not reach 100% or anything near (97-100%), but rather requires my help, consisting of dis-connecting and re-connecting the charger when charging stalls around 60-70%. Full observation log attached.

Spoiler

SuperZaxxon Final - Charging


Explanation of the format:


Date


Time | Battery capacity in % | Predicted runtime | Remark of what I did at that time.


The numbers were noted as seen in the XFCE status-bar.


2012-07-27


11:48 31% 04:27 Connecting charger. Charging-LED turns red.


11:49 31% 11:45


11:58 33% 00:00


12:02 34% 00:00 Screen had turned blank. Closing lid.


13:44 62% 00:00


15:48 82% 132:0 Charging-LED is off. Why has charging stopped?


15:49 82% 75:00 Re-inserting charger-plug. Charging-LED turns red. Closing lid.


17:23 90% 00:00 Still charging with LED on.


17:40 91% 00:00 Opening lid, looking at stats. Suddenly stats are not shown in status-bar.


17:45 98% 00:00 Re-inserting battery. Restart. Now shown as 98%. Nearly complete, thus disconnecting charger.


2012-08-07


13? 8% ??? Automatic emergency shutdown kicked in. Taking battery out. Pause. Battery in. Device boots.


13? 1% ??? After boot is complete, battery level shown as 1%.


13:20 1% 00:00 Connecting charger. Charging-LED turns red.


13:30 6% 00:00


15:48 44% 00:00


18:11 73% 00:00


19:36 75% 125:10 Charging-LED off.


19:37 75% 12:00 After some wake time.


20:08 73% 117:25 Charging-LED still off. Capacity dropped. Charging must have stopped.


20:09 73% 11:59 After some wake time.


20:10 73% 00:00 Disconnecting and reconnecting charger. Charging-LED turns red.


20:39 78% 00:00


06:43 96% 153:33 Charging-LED off.


15:17 89% 134:08 Charging-LED still off.


15:18 89% 13:48 After some wake time. Disconnecting and reconnecting charger. Charging-LED turns red.


15:49 94% 00:00


16:07 96% 00:00


16:56 100% 00:00 Charging-LED off. XFCE Battery monitor only showed strip. After clicking, it refreshed to numerical display.

 

[porg]

No reaction towards the charging issues which I report?

 

[notaz]

Not much I can do since this early-stop is hardware controlled.


There are 2 charge stop / overcharge protection mechanisms in effect now - hardware controlled, when the chip decides battery is full by itself (based on current flowing through the charger) and software controlled, a daemon watching the charge meter to reach 100 and charge current to drop sufficiently. We used to have the hardware one only, but it turned to be unreliable and not ever stop charging for some people, puffing (damaging) their batteries, so that additional software daemon was added (which is not cause of the problem in this case).


It is possible to disable the hardware one (and it would seem to make sense to do since it's unreliable) but that's dangerous, in case someone's pandora crashes while unattended, making daemon dead, it would never stop charging and damage the battery. There are also people running various custom OS that don't have our deamon, so hardware charge stop mechanism is the only effective one there.


There could be other reasons for this behavior like monitoring chip miscalibration. WizardStan did some research and found that it could be larger than expected resistance between battery contacts that could cause monitoring chip not to see correct current flowing and cause it to estimate charge amount wrong. In either case it's all out of software control.

 

[PowerGod]

No reaction towards the charging issues which I report?

I found the latest firmware to be a hive of bugs concerning the battery charge... anyway I didn't had the time to analyze every situation, so I just found the "solution", hoping that .next will be better in that...


When I have to charge I do a reboot, attach the cable even without closing the lid, then, after the red light is on, I can close the lid, BUT I don't put in low power mode while charging, or is a mess... doing this I always have a perfect 100% without red light in the morning.


Anyway I want to underscore something I wasn't aware of and I found in these hot days:


if the battery temperature is too high the charge wont start !!


If after inserting the charger cable the red light stays off, try to type "dmesg" in the terminal to see if there's some battery related message.

 

[steveway]

Small question notaz: Is the logic the charge chip does fixed or is it programmable? If it is programmable, wouldn't this be a possibility to try to fix it for us?!

 

[Linux-SWAT]

There are also people running various custom OS that don't have our deamon, so hardware charge stop mechanism is the only effective one there.

I don't know if i have ^^.

 

[notaz]

Small question notaz: Is the logic the charge chip does fixed or is it programmable? If it is programmable, wouldn't this be a possibility to try to fix it for us?!

Sort of, there are a few parameters, but there is no one to do research on them. I think WizardStan tried some tuning without much success.

 

[porg]

Notaz: I just sent in my Pandora for repair (purple tint of death, left shoulder button broken, microphone not working, USB large connector with loose contact), so now would be the chance to give additional instructions ED on doing power-chip related repairs, i.e. replacing the fore-mentioned wrong resistor. Are there already some official learnings on this, instructions to forward to ED's repair center?