maemo.org Bugzilla – Bug 999
Brand new N800 stuck in infinite reboot cycle (RSS Feed reader)
Last modified: 2008-12-06 14:19:25 UTC
You need to
before you can comment on or make changes to this bug.
I just received my N800 and after adding some RSS feeds (Planet GNOME) and
listening to the included (one) Internet Radio stream for an hour or so, the
device rebooted out of the blue, and has since been stuck in an endless loop of
It seems like the device gets to some point in the boot procedure and then gets
into the same state that caused the first reboot (maybe after the RSS feed was
refreshed?) and reboots again. The device is not a few hours old and is
effectively a brick to me.
I am suspecting maybe the RSS reader is leaking when the feed is loaded maybe,
causing the kernel to panic or something. Adding an RSS feed is the only
"active" thing I've done with the device.
Any steps to reproduce this? I have added planet GNOME feed (RSS 2.0) and tried
to listen to the radion, no problem here so far.
To fix the bricked device you could reflash the IT-2007 on it as described in
the Support section of www.nokia.com/N800.
Jakub - please have a look at the posts on Internet Tablet Talk, many users are
suffering from reboot loops (RSS is a common factor, as is xterm, as is a
Scratchbox only Busybox that sometimes gets installed to the device by mistake).
Some owners have returned N800s for replacement, others for refund (usually
after at least one replacement). Some have found that disabling lifeguard-reset
allows the N800 to boot successfully, others have had to reflash completely (and
of these, some have found flashing extremely difficult due to the device
rebooting during the flashing process, with different results from Windows and
See also bug #957.
This bug (and also bug #957) should really be blockers on the next release
(severity changed accordingly on this bug). The N800 is simply not ready for
public consumption if the addition of an RSS feed (and other benign behaviour)
can send the device into an endless reboot loop.
(In reply to comment #2)
I do not see connection to bug 957. In Bug 957 users installed xterm and if the
ITT forums that you posted are to be believed God knows what else.
This bug is worth investigating, if we only had steps to reproduce it (I can't
by following the vague description)
(In reply to comment #3)
> (In reply to comment #2)
> I do not see connection to bug 957. In Bug 957 users installed xterm and if the
> ITT forums that you posted are to be believed God knows what else.
The connection is that both bug #957 and this bug are discussing reboot loops
apparently caused by normally harmless behaviour - I quote from the original
post in bug #957:
"Then fails to reboot when turned on. 'NOKIA' on white background shown for
30seconds, then blanks, then 'NOKIA' again. No progress, no progress bar,
no icons. Repeats forever."
That's a classic reboot loop, hence the "possible duplicate" being applied to
*this* bug. With both bugs the end user apparently did nothing obvious to cause
the reboot loop, though granted some unmentioned software may have been
installed much, much earlier which is now only making itself known during the
next boot. In each case the user admits to bening/harmless activity prior to the
reboot loop, either adding an RSS feed (that's been reported on ITT forums at
least once) or adding pretty standard software such as xterm. Neither activity
should result in a reboot loop, but it seems they may be implicated.
I provided the ITT links as further background to this problem which has been
occurring since the N800 launch - at least one user mentions another RSS feed
apparently causing a reboot loop. You may be able to glean some useful snippets
of information from the links, and they should also confirm to you and your
management how serious this problem is (though I suspect you are already aware
of the problem).
Anyway, keep both bug entries open if you like - as long as you get to the
bottom of this bug is all that matters. I'd just have thought a single bug entry
(957 or 999) would simplify matters! :)
Yeah, I've got nothing obvious to say which might lend more than suspicion of
cause, and had not seen those forums (thankfully).
I reflashed the device and have had no problems with it so far. I've been
browsing the web, listening to radio, etc. The only thing I've done differently
is not add any RSS feeds. It's been running for about 12 hours so far with no
*major* problems. It did freeze and reboot once when playing a game, but did not
go into the reboot loop.
Jakub: If there's anything I can try, just ask. I don't really care what I do to
the device so long as it's not a permanent brick. I got it to experiment with,
but given that it is out in the public and users can drop US$400 on the thing,
this needs to be resolved quickly, and I'm here to offer any help I can.
That said, I'm sorry my description can't be any more detailed - I simply wasn't
monitoring my actions for what ultimately happened.
Thanks for the interest guys. Being rather busy here it helps a LOT to have
steps to reproduce and then of course the usual OS version and mentioning what
else is installed.
If you now had it working just fine for a day it would be good to try to
that again. First make a "core-dumps" folder to the external memory card and
then add a feed to the RSS reader. The more specific steps the better chance to
do something about it.
RSS is not in my area and not really open-sourced code AFAIK - much harder to
anything (other than replicating this with steps to internal bug tracker).
There's a bug in RSS applet which can cause this reboot-loop once you've
fetched a feed item that triggers the crash. As the crash doesn't happen
when the RSS plugin is loaded but a short while afterwards, Desktop does
not know how it could protect itself from it on the next bootup. I guess
there should be some "safe" mode which disables at least all Home plugins
if there are multiple successive reboots or maybe it should be something
user can invoke e.g. by keeping some button down when Home starts, or
Home (with its plugins) could be separate from the rest of desktop...
AFAIK the RSS applet crash should be fixed in the next update.
(In reply to comment #7)
> There's a bug in RSS applet which can cause this reboot-loop once you've
> fetched a feed item that triggers the crash. As the crash doesn't happen
> when the RSS plugin is loaded but a short while afterwards, Desktop does
> not know how it could protect itself from it on the next bootup. I guess
> there should be some "safe" mode which disables at least all Home plugins
> if there are multiple successive reboots or maybe it should be something
> user can invoke e.g. by keeping some button down when Home starts, or
> Home (with its plugins) could be separate from the rest of desktop...
> AFAIK the RSS applet crash should be fixed in the next update.
I can confirm this, I had the same issue after adding a new RSS feed (from my
private mediawiki). After some minutes (most likely the time, when the RSS
reader tried to download it) the n800 started rebooting and ended up in a
I have got my N800 two times to this infinite loop now.
Both times the battery ran out (during night) and after I charged it and tried
to start it again, the loop begins.
I don't use RSS -applet but i do use XTerm...
Only way I have managed to get n800 back to it's feets is reflashing it and
installing everything again... (Which starts to be frustating process)
Hopefully this helps to reproduce this bug.
(In reply to comment #9)
> I have got my N800 two times to this infinite loop now.
> Both times the battery ran out (during night) and after I charged it and tried
> to start it again, the loop begins.
> I don't use RSS -applet but i do use XTerm...
> Only way I have managed to get n800 back to it's feets is reflashing it and
> installing everything again... (Which starts to be frustating process)
> Hopefully this helps to reproduce this bug.
It is always nice to know what was your OS version and what applications have
been running at that time when the device died.
> It is always nice to know what was your OS version and what applications have
> been running at that time when the device died.
This bug should be fixed in the latest N800 release. QA???
> I have got my N800 two times to this infinite loop now.
> Both times the battery ran out (during night) and after I
> charged it and tried to start it again, the loop begins.
> I don't use RSS -applet but i do use XTerm...
If this happens with the latest N800 and is not related to RSS applet,
IMHO a separate bug should be filed with information about what extra
packages have been installed.
(I don't know any (recurring) reboots that would happen with the latest
release. I've encountered very, very rarely some single reboot still though)
I've seen this a couple of times (running 3.2007.10-7 plus all current updates,
Made in Finland). The device will not turn off, with the charger connected or
not. Pulling the battery doesn't help (but enables the re-flashing to work).
The only recovery is re-flashing, which always works for me.
Whilst I almost invariably have xterm installed (pretty useless for me without
it), whilst I've had issues with this problem, I've been pretty lean on
installing other applications and deploying scratchbox-built experimental code.
I can't offer any firm suggestions as to how to reproduce the problem, but it
seems to always occur after the device's battery drains. My suspicion (one
that I'll seek to disprove) is that it is in some way related to having
connected to a secure wifi network.
The first time I had this problem was after I stayed in a hotel with a secure
wifi network (can't remember key type). Since then, I've enabled wpa-psk on my
home wlan, and have seen the problem a few times (after draining the battery,
so not that common). I have now turned off the crypto on the WLAN (it was this
way before I started having problems at home), and last night drained the
battery on the n800. This morning, the n800 booted OK.
If anyone else wants to have a go at proving/disproving this hypothesis, it
might be faster to come to a conclusion. Can anyone recommend a good way to
drain the battery fast (other than sleeping on the device, which seemed to do
it last night OK)?
(In reply to comment #12)
Well, after three weeks and no instances of this problem without crypto on the
WLAN I was today going to enable it, but last night my n800 succumbed to this
bug. Note that the battery has discharged fully a couple of other times in
this period, but the bug hasn't occurred.
The only additional mameo apps I've had installed over the past 3 weeks are
Leafpad and xterm. I've also been running syslogd over this timeframe, due to
DUN problems, but this is the first time I've had that installed, so it can't
have been the cause before.
My conclusion is that this bug doesn't seem to be related to using (or having
used) wifi crypto and this was probably a red herring. I sure wish that
flasher3 works on Mac PPC, as I feel a bit helpless when I'm not at home and
don't have my x86 Linux box available to help me get my n800 out of this state.
Please re-test this with latest IT OS 2007.
Sorry guys, one problem per bug. This reporter's problem seems to be RSS Reader
If we used one bug for all variations of the same problem, we could probably
live w/ < 10:
1. device sucks
2. general ui discussion
3. device reboots
4. something crashes
5. networking doesn't work
6. hardware is broken or breaks something
7. software is too slow
I'm not sure if I can actually come up w/ another 3. The point is that we need
to limit bugs to a single specific problem. If people have other similar
problems, they can file new bugs and mention their bug number here so that
others can find them (just enter something like: Bug X, as long as X is a
reasonable number, bugzilla will linkify it for you).
Have you re-tested this with last IT OS release (ITOS 4.2007.26-8)? Are you
able to reproduce this still? Thank you.
Jake - although I haven't experienced this bug personally, I haven't seen any
reports of it on ITT forums for quite some time (probably since the release of
3.2007.10-1) which suggests it is now almost certainly resolved FIXED.
I've had it occur once with the latest firmware, and the device rebooted whilst
refreshing the RSS feeds (initiated from the applet) then got stuck in the loop
and needed a reflash (in a hotel).
Not a blocker.
(In reply to comment #18)
> I've had it occur once with the latest firmware, and the device rebooted
> whilst refreshing the RSS feeds (initiated from the applet) then got stuck
> in the loop and needed a reflash (in a hotel).
In newer releases (Chinook and the previous one) the Desktop going down
(when an applet crashes) will cause it just to be restarted with applets
disabled instead of the device itself being rebooted, so RSS applet shouldn't
be anymore a cause for this.
When the device was in a loop, did the desktop come up before it rebooted?
If not, this is also another bug.
As there was no reply, assuming there were no additional RSS feed reader issues
and things are fine since Chinook/OS2008. (additional issues should get new
bugs in any case)