Release SuperZaxxon - Beta 2 released


I'm thinking we could just set the removable=0 bit and have the fw warn the user on first suspend that you shall not change the SD cards while the pandora is suspended or all hell could break loose... (and do the sync so that if the pandora is not able to resume for some reason, or if you have an emergency need for an SD card, no data should be lost on a pure removal of a card...)
 
ZXDunny found the most efficient solution! :D


Serious now: The first time a user triggers a standby, OS probably should show a warning dialogue "leave SD cards inside while standby, else risk of data corruption, etc…" (with an option "Do not warn me next time"). Or not at all. And simply only add these power mode handling info to the wiki or user manual. Reasonable users will act accordingly, or else suffered the data corruption as an experience and won't do it again. No need to put too much dev effort for handling these exceptions.
 
That is not exactly what I meant by "write down"... I meant, the system could create a file, say "sleepdevices", and in that file it would write informations about every removable media mounted on the Pandora. It would show the user the main information so he is aware of it. When the system wakes up, a window opens and shows the same list as well as a list concerning the current media. If the list is the same, you can proceed, if it is not, it is time to plug them back before resuming the PNDs.


I don't think printing that information is quite relevant... and printers aren't as portable as a Pandora, usually. :p
 
When I start chromium-dev X disappears and I see a tty with the boot-status (startet services etc. ending with xfce4 is running)
 
That is not exactly what I meant by "write down"... I meant, the system could create a file, say "sleepdevices", and in that file it would write informations about every removable media mounted on the Pandora. It would show the user the main information so he is aware of it. When the system wakes up, a window opens and shows the same list as well as a list concerning the current media. If the list is the same, you can proceed, if it is not, it is time to plug them back before resuming the PNDs.


I don't think printing that information is quite relevant... and printers aren't as portable as a Pandora, usually. :p

Write them on what? By definition, we can't trust that the media we went to sleep with are the same media we woke up to.


I believe that we should simply not unmount SDs that have been booted from, and that any user that removes/swaps them while the Pandora is asleep gets what they deserve, and deserve what they get.
 
That is not exactly what I meant by "write down"... I meant, the system could create a file, say "sleepdevices", and in that file it would write informations about every removable media mounted on the Pandora. It would show the user the main information so he is aware of it. When the system wakes up, a window opens and shows the same list as well as a list concerning the current media. If the list is the same, you can proceed, if it is not, it is time to plug them back before resuming the PNDs.


I don't think printing that information is quite relevant... and printers aren't as portable as a Pandora, usually. :p

Write them on what? By definition, we can't trust that the media we went to sleep with are the same media we woke up to.


I believe that we should simply not unmount SDs that have been booted from, and that any user that removes/swaps them while the Pandora is asleep gets what they deserve, and deserve what they get.

This, a thousand times. I don't like the idea of having to carry a printer/scanner combo with me, and to be perfectly honest if Notaz does implement such an insane solution then I'm afraid I'll have to boycott the upgrade and furthermore find some way for my PNDs to detect it and fail to run. Expecting us to carry around such bulky hardware is unrealistic and I really don't think Notaz should continue with the idea. At all.


D.
 
The idea isn't without merit. On suspend, record some information about the SD card into RAM: unique ID, free space, maybe a hash of the root. On resume, do a quick compare of this recorded information as a simple sanity check. If it doesn't match, user be damned and unmount the card before something tries to write to bad file descriptors. It's not a guarantee against tampering, but it is a reasonable safety measure.
 
After 2 early morning calls by incompetent users before I have had a chance to get my coffee I had an idea... (those are always the best).


How about this:


before going to standby, System copies the first 512 Bytes of the card into ram and deletes them from the card. When resuming (and checking if it's the right card) it puts them back. This way


1) you can be pretty sure noone accidentally changed something on the card as it won't be accessible (without work)


2) It has a very educating effekt on mindless people swapping innocent SD-cards while little pandora is sleeping like a rainboy pony.


Arising issues with powerloss should be firmly ignored.


:ph34r:
 
Last edited by a moderator:
The idea isn't without merit.

yes, but I'll be buggered before I start lugging a printer/scanner combo around with me just in case I want to resume my Pandora on the go. I mean, really - Notaz must be off his rocker.


D.
 
Well I'll leave it to ED to decide if he wants this unsafe suspend by default or not. It's him who might be getting "SD eating pandora" RMAs in the end.


As for the innovative/crazy ideas of collecting info about cards then comparing or asking the user questions on resume, that would require pretty extensive changes to Linux PM/mmc core so it's not going to happen unless somebody else wants to do this. Changes like this would also be total nightmare to maintain on kernel updates.
 
As for the innovative/crazy ideas of collecting info about cards then comparing or asking the user questions on resume, that would require pretty extensive changes to Linux PM/mmc core so it's not going to happen unless somebody else wants to do this. Changes like this would also be total nightmare to maintain on kernel updates.

Thank god you've come to your senses at last. I don't have room for any extra hardware in my pandora's case.


D.
 
In my opinion, the best way would still be to try to unmount the card and go into low-power saving mode (without unmounting the SD Cards) if an unmount is not possible.


Maybe showing a small notice for a few seconds about that before going into that mode.


With the new kernel, the differences between real standby and the low-power-mode are not THAT big, based on my experience.


Most of the time I just leave my Pandora be, without going into standby or low-power mode, and the power consumption is very low already.

As for the innovative/crazy ideas of collecting info about cards then comparing or asking the user questions on resume, that would require pretty extensive changes to Linux PM/mmc core so it's not going to happen unless somebody else wants to do this. Changes like this would also be total nightmare to maintain on kernel updates.

Thank god you've come to your senses at last. I don't have room for any extra hardware in my pandora's case.

Eh? notaz never was in favour of anything like that?
 
ZXDunny was just constantly joking by giving "writing down" an exterior physical meaning (print out to paper), rather than "writing down the SD serial/hash to a place in RAM or NAND", which was actually meant.
 
notaz: nothing personal, he was more making fun of a comment by someone else that was pretty much nonsense. You can just ignore his ranting as you won't think it's funny and/or personal when you understand it.


standby can still be triggerd by a script, can't it? we can just test EDs assumptions then. Like compare after 5 hours of standby/suspend from ~100%. I'll make that test here, would be glad if others did the same.
 
Last edited by a moderator:
standby can still be triggerd by a script, can't it? we can just test EDs assumptions then. Like compare after 5 hours of standby/suspend from ~100%. I'll make that test here, would be glad if others did the same.
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.
 
In my opinion, the best way would still be to try to unmount the card and go into low-power saving mode (without unmounting the SD Cards) if an unmount is not possible.


Maybe showing a small notice for a few seconds about that before going into that mode.
Was going to argue with that (PNDs on SD card and therefore open files being the default use case and all that) - but tbh since it's clear that it's a kernel option that can be changed easily upon boot, I don't have any strong feelings either way.
 
Still no idea what this has to do with me or anything that I said.

I was just expressing my relief that you had decided not to go with the printer/scanner solution, that's all. Carry on :-D


D..
 
@McLovin: Since yesterday I am performing comparative battery runtime studies under the different modes (standby / low power mode).


Will post my results in 1-2 days, as longer runtimes give a better estimation.


For my tests I establish low power mode by closing the lid, establish standby by sliding the power switch, hope this is the right assumption.


With a particular study interest in whether power consumption in low power mode differs between "idle OS, no active PNDs" compared to "PND game running or with paused gameplay".


What is the requirement, that the system goes into low power mode by itself? What will hinder this from happening?
 
Back
Top