Release SuperZaxxon - Beta 2 released

[notaz]

How do other distros do it? I can start playing a video from an external hard drive, suspend my computer, even go so far as to turn off and on that external hard drive, then un-suspend my computer and the video will resume playing with no apparent problem. Is this a function of the kernel or is this mplayer catching that the file descriptor has vanished and manually re-opening it at the same spot?

I don't think it actually unmounts the hard drive.


Maybe we could add "allow PNDs to suspend/I understand that if I change cards while suspended they will be corrupted" option, that will just stick kernel argument mentioned a while back (or was it in kernel issue thread).

I don't understand why apps can't just be taught to listen to SIGSTOP/SIGSTP and then have something (daemon? kernel?) send these signals on suspend and resume. Oh, I guess I understand .. its something we'd have to get everyone to implement, or?

SIGSTOP is not a signal programs can catch. We could maybe add some other notification method, but yeah problem is everyone would have to implement this stuff. Maybe add something and see if anyone starts implementing, still better than nothing..

Dear jottt!


1) Thank you for being another supporter, that standby with active PNDs is desirable.

I don't understad why you act as if somebody doesn't agree with you - the problems preventing this are purely technical, not someone's decision not to implement this.

 

[porg]

I don't understand why you act as if somebody doesn't agree with you - the problems preventing this are purely technical, not someone's decision not to implement this.

So far jotttt was the only who also verbalised his support, and ED and you notaz sounded a bit defensive.


Now, I know that you all agree, that "standby with active PNDs" is a goal, just the implementation must be figured out.

Maybe we could add "allow PNDs to suspend/I understand that if I change cards while suspended they will be corrupted" option, that will just stick kernel argument mentioned a while back (or was it in kernel issue thread).

I guess putting implementation duties towards the PND developers, has little chances for realization, as the PND standard is intentionally very minimal, the implementation of the app itself has almost all freedoms (no binding standards as on restrictive platforms such as iOS).


As a OS layman, I thus naively propose that the OS ensures that RAM and FS state is the same before/after sleep, the PND apps not needing to have any awareness of pause/resume, the only surprise being an offset in the system clock.


If it is a technical requirement, that the SD card remains in the Pandora, I guess it is reasonable for a user to follow that requirement, if s/he puts the Pandora to sleep.

 

[jottt]

SIGSTOP is not a signal programs can catch. We could maybe add some other notification method, but yeah problem is everyone would have to implement this stuff. Maybe add something and see if anyone starts implementing, still better than nothing..

SIGSTOP won't work (if you want the app to be aware of sleep) but


should not SIGTSTP work as the "nice" sleep signal, so programs are actually able to catch it and process it however they like, if they want to? Thats what I understood, it might be wrong, I'm not a coder.

 

[sebt3]

The SIGSTOP sent to suspend PND apps is there since... the beginning. I'm missing the reason of all this fuss for this release

 

[jottt]

The SIGSTOP sent to suspend PND apps is there since... the beginning. I'm missing the reason of all this fuss for this release

I don't think it's generally fuss for this release (at least not for me). I'm quite happy already, others wish for more suspend-features. Ideas arise and get slashed...isn't that quite normal for a creative process as long as it does not get hostile or destructive?

 

[WizardStan]

The SIGSTOP sent to suspend PND apps is there since... the beginning. I'm missing the reason of all this fuss for this release

The problem isn't stopping the processes, it's that when the new kernel goes into suspend it unmounts the SD cards, killing all open files. A mounted PND is suddenly mounted nowhere; even if the PND could be remounted in a way that the running process could continue, all of its files will have been closed by the unmount and unless the process is smart enough to recognize so, it will attempt to use these closed files and crash.

 

[fusion_power]

The magic is contained in *nix since many years and called process suspend, aka SIGTSTP and SIGSTOP. You can send (nearly) anything to sleep in a blink of an eye, leaving it only occupying RAM, but using no CPU cycles. iPod probably does not always to a full stop I guess, as some applications still work in the background. This pretty surely works on the pandora as well as any *nix. It does NOT take into account that it's working directory vanishes, which will happen if you remove the SD-card (when entering sleep). So I am pretty sure, IF you copy your PNDs to the local drive (and the sleep does not force-unmount the PND) it will survive the sleepmode.


The iPod is no magic at all at this point. It simply does not have to considerate external storage.

Dear jottt!


1) Thank you for being another supporter, that standby with active PNDs is desirable.


2) The functionality of iOS (and Mac OS X 10.7 Lion), which you mention, is not only standby functionality in the classical sense, but an extended technique, called "Automatic Termination" (Apple Dev Doc, Ars Technica Review). Apps serialize their current state (save their whole state to permanent (disk or flash) storage), and set a flag "ready for termination", and the OS decides when to kick them out of memory, and when it is needed again (user switches to this app, or it partially gets visible again), the OS triggers the app again, and its initialisation recreates its state from the serialization from permanent storage, and the user finds his program in the state where s/he left it.


Nr.2 is unrealistic to realize for the Pandora, as the PNDs come in a flavor of different programming/API styles,


but nr.1 should be achievable, as WizardStan reports, and as I know of from all kind of Linux devices.

Thanks for the explainings. So do these started and then suspended but still active apps there fill the RAM or are they just some kind of active links that resume it's last state back from Disc when awoken again? I can't imagine they need much RAM, my buddy had alot of these apps started and was able to browse in the Web pretty fast and play 3D games during there werde other apps started.

 

[centus]

At the risk of sounding like a complete idiot, this is Linux, why can't we change the kernel sleep routine to make sure it does not unmount the SD cards?

 

[fahrstuhl]

We can, but if you do so and swap a SD card while in standby, data corruption occurs.


My SD cards aren't exactly useful outside of the pandora, so I can't see that happening to me. I think I'll just roll with that kernel option.

 

[WizardStan]

At the risk of sounding like a complete idiot, this is Linux, why can't we change the kernel sleep routine to make sure it does not unmount the SD cards?

The kernel isn't doing the unmounting.


As I understand, what happens is that the suspend script unmounts the SD cards before going to sleep. The reason it does this is because, reportedly, if you eject an mounted card while it is suspended you are almost guaranteed to get card corruption. I don't know the nature of this card corruption though. I seem to recall Notaz saying there was an option to not unmount and user beware if things should break on them but I can't remember where it was. If I can find it, you can guinea pig it for us

 

[fusion_power]

Maybe some optional unmounting "blocker" for suspend mode with a fat red warning sign not to remove the SDs when activated?


At least now I know why this iPod Touch doesn't have any SD slots or removable data storage at all. Everything is built in, not even the battery is removable. At least I didn't spot any screws on the back, it is sealed like Fort Knox.

 

[sebt3]

The kernel isn't doing the unmounting.


As I understand, what happens is that the suspend script unmounts the SD cards before going to sleep.  The reason it does this is because, reportedly, if you eject an mounted card while it is suspended you are almost guaranteed to get card corruption. 

sync;sleep 1;sync;suspend


should do it

 

[fahrstuhl]

At the risk of sounding like a complete idiot, this is Linux, why can't we change the kernel sleep routine to make sure it does not unmount the SD cards?

The kernel isn't doing the unmounting.


As I understand, what happens is that the suspend script unmounts the SD cards before going to sleep. The reason it does this is because, reportedly, if you eject an mounted card while it is suspended you are almost guaranteed to get card corruption. I don't know the nature of this card corruption though. I seem to recall Notaz saying there was an option to not unmount and user beware if things should break on them but I can't remember where it was. If I can find it, you can guinea pig it for us

This one?


Although you probably need to edit the suspend script, too.

 

[WizardStan]

sync;sleep 1;sync;suspend


should do it

If it were that easy I'm sure Notaz would have done it. That was the first thing that came to my mind as well, and you aren't the first to suggest it either. There's more going on than I claim to understand.

 

[slaeshjag]

The real problems start when you resume with a new SD-card, the kernel will carry on as if the old one was still there, with the possibility of the kernel blindly overwriting stuff on the new SD-card according the the structure of the old.


It would of course be possible to patch the kernel to do something simple like checking the card serial number before and after suspend. If they differ, kill off the PNDs and unmount the card. If not, continue. This still have some risks, most notably if the card is removed and modified and then put back into the pandora. That could cause some serious trouble. Maybe it's possible to flush all caches on the FS status?

 

[porg]

Dear Fusion_Power: The OS vendor (Apple) defines that all apps must have a way to de/serialize their whole state. The OS dynamically decides which apps stay in RAM (front most, visible, recently used, and other factors) and which get the "serialize now" and "auto terminate now" signals.

 

[porg]

Again: It is reasonable to inform Pandora users, that SD card removing/switching while standby, will result in data loss, and should thus not be done.


If this is indeed the only technical worry preventing the implementation of standby-with-pnds.

 

[porg]

On my Windows & Linux operated ThinkPad laptop in sleep mode, I could even disconnect and reconnect USB storage devices and wake up and resume using them without any problems. As long as I don't connect them to another computer and change the USB storage device's data there, which would make it inconsistent with the state of the sleeping computer. Possible a read-only access on another computer would even be possible, without causing problems, when later re-connected to the sleeping computer.


On my Mac laptop I could not do this, as dis/connecting a USB device triggers a wake event.

 

[fredg999]

I think the system, when going to sleep, should write down the SD cards and USB storage devices plugged in at the moment, then tell the user about it so he/she can make sure to have them back in when it is time for the system to wake up. Once it does so, the system would look at the SD slots and USB ports and would see if they are all present or not, in which case the user would be warned before the applications are resumed. When everything is okay, resume the PNDs, and if there are PNDs to abort or to keep in pause (let's say you lost an SD card or whatever could happen to it).


Copying the PNDs to the NAND to avoid corruption, like proposed in some post before me, is risky I think, because the NAND is already quite full and I doubt there would be enough space to load several PNDs, for multi-taskers. Also, we can't prevent the user from removing the SD cards and USB storage devices, so this is what I propose. I don't know if that is hard to do technically, I'm basically brainstorming.


Also, when going in sleep mode, does the user have to log in with the password and all again?

 

[ZXDunny]

I think the system, when going to sleep, should write down the SD cards and USB storage devices plugged in at the moment, then tell the user about it so he/she can make sure to have them back in when it is time for the system to wake up.

This. +1.


Actually, it would be really handy if the user could be prompted to attach a printer to the USB port so a list of devices could be printed out on handy business card-size sheets, which would be quite easy to fit into a wallet, thus keeping with the "portable" theme the Pandora engenders. If we insist that suspend not go ahead until that card has been printed, we could then ensure that data corruption is kept to a minimum.


In fact, why not go the extra mile? Most printers are scanner/printer combos now so we could have the Pandora require that the list be scanned back in before the pandora resumes from sleep mode then we could really get this problem licked.


D.