Sorry for not posting "the rest" but I forgot what it was. Today I had batterry/charging bug I suppose. I couldn't boot my device for long time after crash or emergency shutdown. It succeeded without reflash after long time of retries. The reason why I think it is related with batterry state is the batterry was almost empty at the shutdown or another problem forced my device to shutdown.

I want also to remind old known bug I suppose - in kernel power with multiboot implementation (read it as - not direct booting only kernel otherwise) it fails to boot properly into system while charger is connected - it seems to lock at ACT-DEAD state despite trying to leave it in a way which worked previously. I don't know if it is the same bug as one from ages but rarely occuring or it was new since Kp51 - but I feel forced to remind that - even if user resolution/workaround is trivial - just to disconnect charger, boot up until desktop shown and reconnect it. I hope you would find some time to adress that.

PS: the time it failed to boot was too long for the time it having too low batterry to do the manuever, and I also had the fbcon log with error which I couldn't catch long enough to know what were written, but long enough to see there was at least one then.

EDIT: it seems reseting the device by pulling out batterry for 30 seconds were neccessary to recover non-booting problem but not enough anyway.

---------------------------------------------------------------

it seems from the behaviour that kp51 after "full" batterry and wallcharger present tries to overcharge the batterry by mistake but it may be wrong device Charging Reporting behaviour under kp51.

It did work.

What am I doing wrong?
I'm trying to load the injection drivers but it dosen't work!

and its giving me error that My kernel version does not support injection
Or sometimes its just go one line down and dosen't write nothing.

Today I had Kernel Crash. After it it rejected trying to power up. Wise by previous experience I removed the battery (and put in after 30 seconds) at it booted properly at first time after reset. After booting it showed info about kernel crash (blah blah not properly blah blah custom settings reseted) and message looking like "batterry almost empty". So I checked it by bnf and it was at 33% (nokian batterry meter showed small red stripe) and restored my custom settings ("kernel-config load MAJC89" and "kernel-config default" from root console). Then I restored my date and time over internet by some "ntpd -s". Used it a much for 30 minutes without a problem and it shutdowned itself again (but now because of real batterry discharge). I'm now recharging and boot was clean (booted properly at first time, no settings-reset message, and guess what - it didn't bugged boot up, despite charger beeing present and connected - no wallcharger bug this time at first boot trial). I'll check if any charging bug will occur or if my N900 piece is cured for at least a day (all the kernel-power power-maintenance bugs seems to have some trigger without which, they don't seem to occur at all).

PS: I noticed that during my kernel crash I had mediabox (which is audio/video player) running and playing and headphones on my head. It were playing with stutterring for 3 seconds after screen went off. It may be related because mediabox during switching tracks with shuffle (which lasts between 50ms to 750ms) seems to be on 100% processor which triggers my overclocking settings temporary for the fragment of second to 900 mhz (and after it returns safely to 500 mhz which is my minimum in my kernel-config profile - I checked it with freq-watch.sh which i noted from the quote when I wanted to know why "kernel-config show" show the 900mhz and then it was obvious that kernel-power-config fails to measure the current frequency because it use too much processor resources, so I found the script very helpful for the task that "kernel-config show" fails to do). I remind that I previously late time ago (when latest VDD2 patch came in) I tested it can stand 900mhz for 15 minutes without single problem, so kp51 was partially the reason (either my kernel-config profile is valid or beacame invalid after update to kp51 and my profile didn't changed since then).

http://www.debian-administration.org..._in_14_seconds

we can do this on n900?

kernel is already optimized for device, it doesn't have to run anywhere else so all required functionality should be built in. wifi drivers aren't because of need to swap with injection drivers.

if your looking for fast booting, your best bet would be to replace the current init system with systemd or maybe upstart. however, with systemd, this would involve reworking all the current init scripts to become .service files to make the most of it.

question is, is it really worth it? device has long battery life compared to laptop. its usually not (re)booted very often as it needs to be always on.

edit: appaerently already uses upstart.

@Android_808
i just meant that the phone should boot between 7 to 8 seconds. thats it

@majaczek-how did you judge you had a kernel crash? It could be that I miss something, but I fail to see your crash backtrace (/dev/mtd2). Could it be that your battery no longer holds the charge and the device has shut down? Also you use some custom OC profile-care to share it?

might be limited due to i/o speeds or upstart version lacking some optimization. if an initrd is used it tends to slow it down a bit. can't tell at the moment, rather worryingly /boot appears to be empty, despite kp and k listing files installed there.

my eee 1000 with standard ssd's and a 2gb ram upgrade will easily go from grub to lightdm login screen in 4.8s according to systemd's analyize app. with a slower processor, less ram and probably slower flash memory, i imagine n900 with tuning will still be more than 8.

if it's something your interested in looking into, start another thread as it's a bit off topic here.

n900's flash memory and microsd cards are a lot slower i/o-wise than SSDs, and so are the rest of the specs