Hi again.

So looks like Inodes are not this issue only 10%

Memory looks fine and just to be sure I freed up more RootFS space so now have 86Mb free there.

I have apt-get removed several app's to tidy it up more.

I still have the problem.

If I run the top command in xterm I see a number of resource hungry processes running after boot up. But then it seem to settle down with processes using low single digit CPU and single digit memory.

Once the error occurs again there is no apparent change in the the Top command results, it shows plenty of CPU and Memory resource available. and there are no resource hungry processes apparently runnning.

The error occurs and then it increases in frequency until it triggers a reboot.

I was connected with putty at one point and was apt-get remove tracket-cfg to make sure it wasnt a tracker-cfg issue. The error became more and more frequent and the phone rebooted and broke the putty ssh connection. I had to reboot and use xterm on the phone to finish the removal of the tracker config app. Strangely since then putty will not connect (connection refused) via ssh to the phone. Not sure if it is linked to my other issues...

Currently running a test without the SD card installed to see if there is something strange there.

Process PID 1666 running almost 100% of CPU and 43% memory 5 minutes after reboot. any idea what PID 1666 is ?

Could be anything: pids are of course allocated dynamically.
What does 'ps aux | grep 1666" say?

I am next t sure but afair the ext3 home partition is created with a buffer of 10% free inodes. I say not sure but as soon as I saw the output it made 'click'.
You need to find directories where a lot of small files are stored. They do not fill up space but using inodes.
Please see e.g. here: https://scoutapm.com/blog/understanding-disk-inodes
https://stackoverflow.com/questions/...mber-of-inodes

did not see the other posts but still I think you ran out of inodes on /home. 10% free does not mean they are available.

Hmmm, seems to be a "calendar" process.

The table format when pasted here is hard to decipher - but it is saying (i think) for /home/opt 128k Inodes created, 17K used and 111K available (13% used).

Nokia-N900:~# df -ih
Filesystem Inodes Used Available Use% Mounted on
rootfs 0 0 0 0% /
ubi0:rootfs 0 0 0 0% /
tmpfs 28.7K 51 28.7K 0% /tmp
tmpfs 28.7K 35 28.7K 0% /var/run
none 28.7K 728 28.0K 2% /dev
tmpfs 28.7K 3 28.7K 0% /dev/shm
/dev/mmcblk0p2 128.0K 17.0K 111.0K 13% /home
/home/opt 128.0K 17.0K 111.0K 13% /opt
/opt/pymaemo/usr/lib/python2.5
128.0K 17.0K 111.0K 13% /usr/lib/python2.5
/opt/pymaemo/usr/share/pyshared
128.0K 17.0K 111.0K 13% /usr/share/pyshared
/opt/pymaemo/usr/lib/pyshared
128.0K 17.0K 111.0K 13% /usr/lib/pyshared
/opt/pymaemo/usr/share/python-support
128.0K 17.0K 111.0K 13% /usr/share/python-support
/opt/pymaemo/usr/lib/python-support
128.0K 17.0K 111.0K 13% /usr/lib/python-support
/dev/mmcblk0p1 0 0 0 0% /home/user/MyDocs
/dev/mmcblk1p1 0 0 0 0% /media/mmc1
Nokia-N900:~# for i in /*; do echo $i; find $i |wc -l; done

I used this:-
for i in /*; do echo $i; find $i |wc -l; done

to look at the /opt ones and eventually tracked down the biggest part 8.9k Inodes to /opt/../microb-engine/chrome and it seems that most of it is some sort of language files each with about 149 inodes.

/usr also was giving a large number of Inodes and the biggest was /proc with 28k Inodes.

But if my interpretation of the table is correct, it doesn't look like and inode problem.

BTW the Putty/Openssh not connecting issue was eventually solved by uninstalling openssh (client and server) and then installing them again.

I think I have found out what the problem is, based on the high resource demands on the calendar process. It part of the same MfE problem with contacts duplication, but this time is it calendar entries, some are duplicated 160x!! And they are series events so 160x every year until 2037!

You sure have a busy calendar!

Yeah! Worst thing is they are now back synced to outlook, and there is no easy way to remove the duplicate entries! Just select, delete, whole series, ok each time.

I think I managed to find them all. so waiting to see if the N900 will sync and remove the duplicates seeing that they were removed on outlook. If not I will delete the MfE account and try again...

And I can check how android manages it on my other phone, as its got the same problem with duplicates now. Obviously more processing power means its not crying about it like the N900 is!

I am surprised that MfE even works for you on the N900 at all. The last time I used it, it synced only once a day, after my commute to work, when it switched from the mobile network to the company WiFi. Which was kind of useless: I did not need my work emails on my personal phone in the office!

(Mind you, the Exchange support in Sailfish is even worse. My last successful sync was weeks, if not months ago. I gave up and removed Exchange altogether. How can something supposedly actively maintained be worse than something abandoned years ago is beyond me.)

So, yes. You are definitely right about the inodes thing. Should have read the figures more proper

But then I do not get where this message came from?
Was disk space low? Nope.
Was/is this message really about RAM? (then it should have popped up every day for everybody )
Or was it 'only' low 'disk space' on /tmp (to check with a normal df -h)?