Hello,

Yesterday I've tried to install Debian Squeeze to the device, so I've created a 2GB file and connected it as a loop device, then formatted it with ext2 (and later ext3) filesystem.

So I've mounted this image to a directory, then tried to run debootstrap into it.

N900 rebooted on unpacking the files to it (I had to enter device lock code and lost the ssh connection).
After it, I've tried to run with nice -n 19.
I was able to debootstrap the system once, but it rebooted when I've tried to install other applications (on unpacking), I've started it also with nice.

I've tried to debootstrap again with nice (because filesystem corruption inside the image file), but it rebooted again.

Sometimes it just switched off...

Anyway, the phone is stable with everyday usage, it is able to run for weeks without reboot.

I think this is something like a "watchdog"... The system has Community Update and kernel-power installed.

What am I doing wrong?
Do you have any suggetions?
How could I play with other Linux distributions without reboots happen?

It works well when I try to install applications on the base OS.

Any help or suggestions are much appreciated.

And how much overclocking/undervolting have you done?

It does it without overclocking or undervolting.

Maybe the busy flash media can be a problem, but I've also tried on its internal memory and on a uSD card.
Anyway, I don't know how to limit disk IO for this purpose...

Now I've tried it again with CPU speed set to maximum of 250 MHz with qcpufreq (and SmartReflex turned off).

It started to unpack system packages, then I saw it seems to be halted... the terminal seemed to be died and the phone didn't turn on the screen.
Later, I saw the Nokia logo on the screen without backlight and the phone switched off.

Also, I saw the terminal (via SSH) has been changed compared to the state above, it continued to unpack packages before the phone shut down. (So it wasn't die before, just extremely slow.)

So I think it happened because of the high load, since the phone was unusably slow before it.
I don't know if it would restart instead of shutdown, because I've pressed the power on button early.

What are you suggest to do to be able to use Debian via chroot and prevent system shutdown/reboot temporary?

luckey you. i have one of the newer models, the chip cant seem to take much ocing. if its at a high load at 700mhz is crashes...

Mine crashes under heavy load. It always has.
Or it freezes and won't come back.

I've had times where it's forced a reboot by it's self and all I had open was three microB windows and I received an sms.

Interesting...

Anyway, I haven't really used it with stock kernel.
Maybe I will give it a try how it is work compared to kernel-power.

I don't really know the phone's age, but it is not one of the latest model I think.

I don't know how to determine it.

I have experienced a same/similar behaviour using dd, creating large files for holding images (ext of vfat FS) or even swap files.
Having KP47 and also swappolube activated/deactivated. Same. I think, its the hig IO load slowing/starving the N900?
Once the files are created, I can use them normally, like ED and installing inside or outside, everything works (unpacking complete image is also high IO load, so may crash).
At the moment I do not need new large files, but nevertheless would like to know how to solve that.

P.S.: as dd always crashed, I was successful with truncate from ED, adding byte-by-byte ...

Thank you your answer.

I think IO load is my problem.

It would be good to find a solution to take all IO caused by chrooted environment to background or just slow it down to a lower speed.

First set all your swappolube/whatever to defaults or uninstall so it doesn't interfere.

Then:
Unpack or perform your heavy IO load.

After:

I found this helps alot with large IO.


As for deprioritizing stuff, the kernel is totally unaware of the properties of flash based media. Heck, almost all developers and users too. The throughput of writing to flash will vary between about 64 kbyte/s and 12 megabytes/s depending on how seek-heavy/random the IO is. The kernel mostly assumed storage devices behave like harddrives.

Making the disk queue bigger allows for sorting requests over a bigger range making them less random. Temporarily setting swappiness to 1 will make the kernel favor dropping the executable areas of apps from RAM and swapping them back in on-demand from storage again. As most of the OS is on the nand, this shifts load away from emmc during your heavy-IO operations. Even for /opt it helps a bit as read requests from emmc mixed with writes don't interfere too much with writes.

Downside of swappiness 1 is that once the memory pressure becomes big enough to require swapping of anonymous memory, which is data created runtime by processes, has no copy on storage and thus needs writing, the already large drop-from-RAM and read back bandwidth will get squeezed smaller with the relatively expensive writes, of which there'll be lots in a sudden burst.
Swappiness 100 gives a steady trickle of both behaviours, and you get a more smooth transition with only small interruptions, most too small to be noticed, getting bigger as memory pressure increases. Swappiness 1 tends to be fast and smooth until a certain point at which you get massive long interruptions.