Pandora wakes up on SD card insert or eject

[bukkit]

... it might be considered a feature, but in fact, I find it annoying and it tends to wreak more havoc than it ever could prevent.


So, is there a way to prevent the Pandora from waking up from power save when a card is inserted or ejected?


(Searched and didn't find anything, sorry if I overlooked something.)

 

[Pickle]

be aware removing sd cards during sleep mode may cause data corruption. So really you shouldnt be doing it.

 

[Binky]

Wouldn't it be better to remain asleep, so you can put the card back in without risking further corruption?

 

[bukkit]

Thanks, binky, that's what I tried to imply in my posting above by "it tends to wreak more havoc than it ever could prevent". Data corruption lies with both options. Grant me knowledge about what I'm doing and then you'll find that the Pandora might be corrupting *less* data if it just stays asleep while I gently read data from it's cards. However, woken from it's slumber, grabbing onto the missing card, it might damage it's state of mind, alter consciousness, and the OS (especially if placed on the card) finds itself unrooted, panics, processes die. Files will be unwritten and unclosed.


If mayhem is possible either way, let the user choose the way mayhem occurs, to reduce actual mayhem depending on user behaviour, that's what I'm saying.


Therefore I re-iterate my question: Is there a way to prevent the Pandora from waking up?

 

[_wb_]

Ideally the behavior would be as follows:


- if the ejected SD card contains the OS, don't wake up and hope that the card will be reinserted and not be modified before getting back from sleep


- otherwise (if an SD card gets inserted or a non-OS SD card gets ejected), wake up to do the automount/unmount and scan for PNDs etc, go back to suspend automatically.


This would mean that when you switch SD cards while the device is suspended, at wake up the new cards are available instantly.


On the other hand, it's really not very good practice to touch the SD slots while the device is suspended, so maybe you should just not do that. I suspect the above ideal behavior is not that easy to implement.

 

[bukkit]

I concur with the implementation aspect. I don't think the hardware can be modified to discern between insert/eject while suspended and change behaviour accordingly. I also wouldn't mind if an insert in suspended state would be deferred until the next wakeup. Therefore my ideal behaviour would be to just stay suspended. No, actually, ideal would be a configurable behaviour regarding card ejects and inserts in suspended state.

 

[skeezix]

..... or you could spend the 5s on each end, to restore and suspend it, and not have corruption I dunno about you, but data integrity is high on my list


I imagine the action could be controlled by a kernel change; anyone up to it?


jeff

 

[Binky]

Should behaviour depend on whether the card it write-protected?

 

[bukkit]

..... or you could spend the 5s on each end, to restore and suspend it, and not have corruption I dunno about you, but data integrity is high on my list

I think I'm not understanding what you mean by "to restore and suspend it" ... unmount and mount?


If so, it doesn't suffice if the OS is on the SD. There, I need a full halt and reboot every time I want to read a file from the SD.


I dunno about you, but my time is costly


Also, I'm sometimes sloppy and eject the wrong card or believe I had unmounted and haven't. The Pandora waking up prevents me from correcting that error quickly and so it wakes up into the mess.

 

[bukkit]

Should behaviour depend on whether the card it write-protected?

Interesting proposal. But for me, it's most often the OS SD I want to eject without fearing corruption and without having to reboot. There, write protection is not an option. Also it would require me to know before I insert a card if I rather would write something on it or eject it later, and switch accordingly. If I was wrong, I'd have the same trouble I'm having now. And I couldn't start a pnd from a write-protected card. So for me, not really an option.

 

[skeezix]

deleted; was an okay post, but I'm too tired to make a point without sounding silly right now

 

[Mr_Loon]

@ Bukkit : I'm confused, why not just wake the Pandora before changing SD cards? This takes only a few seconds. Also why would you want to eject a card which was running the OS?

 

[bukkit]

@ Bukkit : I'm confused, why not just wake the Pandora before changing SD cards?

I'm confused, too. Wake her up before she awakes? What's that supposed to achieve? Sorry, I don't get it. Why not just let her sleep? Is my question.


Why wake, unmount, eject, sleep, read files, insert, remount, sleep to achieve the effectively same result?


And to prevent data corruption. (Hm, btw, not wanting to sound rude, but I explained everything a couple of times here.)

This takes only a few seconds.

A full reboot takes more like minutes. And ejecting the card with the OS takes a full reboot. Time is lost. And the session is lost. Screens are lost. Without any gain.

Also why would you want to eject a card which was running the OS?

To read files from it.

 

[Binky]

Use the USB slave mode?

 

[bukkit]

Of course I know that option, and it's possible, but I often don't have the cable at hand. Also, you know, waking her up, using battery, finding cable, enabling host mode, using more battery, plugging cable, (doing work), ejecting usb, ending host mode, shutting down, stowing away cable ...


I'll just repeat: Why. Not. Just. Let. Her. Sleep.

 

[bukkit]

Now it happened: Somehow the SD card was ejected while the Pandora was in an Ultrabox.


Result: Pandora switched on, battery got drained, Pandora blanked when battery was empty, card was damaged.


Really, this wake-up-feature isn't helping. It doesn't prevent anyone or anything from ejecting a card, it only guarantees that an eject, accidental or not, results in damages.


I'm willing to scratch leads on the board, whatever, to discourage this destructive behaviour. Any hints by hardware guys, eventually?

 

[WizardStan]

What is this? It shouldn't be doing this, not at all. I just tested it with a secondary card (bunch of stuff I didn't really care to lose) and it sure did wake up, resulting in a thrashed SD card. It was recoverable, incidentally, but I had to run chkdsk on a Windows machine.


Anywho, this is not expected behavior. To the best of my knowledge, the TWL has three wake-up triggers: applied power, switch, and timer interrupt. There is no reason the SD card, either insert or remove, should be setting this off. I'll have to do some investigation.

 

[Linux-SWAT]

Maybe linked:


I already reported that when suspended to ram, the OP wakes up ~20mn after. You just have to move nubs to see the screen on.

 

[bukkit]

Anywho, this is not expected behavior. To the best of my knowledge, the TWL has three wake-up triggers: applied power, switch, and timer interrupt. There is no reason the SD card, either insert or remove, should be setting this off. I'll have to do some investigation.

This is a relief. I already felt I was preaching to walls here. Glad you're in on this.

Maybe linked:


I already reported that when suspended to ram, the OP wakes up ~20mn after. You just have to move nubs to see the screen on.

Interesting. I also had that from time to time, but I wrote it up to me being sloppy somehow. But I don't think these are related. The one is a hardware-related, exactly reproduceable behaviour, the other sounds more like a intermittent glitch with a failed suspend...