Comment 1 Eero Tamminen 2009-11-27 10:23:52 UTC

"Bricked" means that it doesn't boot up anymore?

Which state the boot reaches before it stops (or reboots)?

the devices freezes in 5 white balloons state, just before the UI would
nolrmally be broght to screen. second balloon from left being the bigger one.

Comment 3 Eero Tamminen 2009-11-27 11:51:29 UTC

> EXACT STEPS LEADING TO PROBLEM: 
> wait for random reboot

Is this sw_rst (SW watchdog graceful shutdown & reboot) or 32wd_to (HW
watchdog) reboot?  Former shouldn't be able to cause this kind of issues[1].


(In reply to comment #2)
> the devices freezes in 5 white balloons state, just before the UI would
> nolrmally be broght to screen. second balloon from left being the bigger one.

PIN code query and and the startup sound work fine?

After it freezes, it doesn't reboot at that stage, just stops?

Does shutting down the device, taking the battery out, putting battery and
back-cover back and then trying to boot help?  (Unlikely, but worth a try)


If you shut the device down and wake it up with the USB cable (connected to a
PC), does the charging (which doesn't boot up the device fully) still work
fine?  I.e. the device screen lits to show the Nokia (+USB) logo and after a
while the screen blanks with just the LED indicating that it's being charged.

If the charging worked, do you see the device as USB storage device on your PC?

If you see it, can you check the file system consistency with PC?  If there's
some problem, try repairing the file system and then (long) press the power
key.
Does it now boot up?


The thing I'm trying to determine is whether the reason for the freeze is
/home/ or /home/user/MyDocs/ file system getting corrupted.

If you have the reboots also in the future, you could check after each
(32wd_to) reboot that the MyDocs file system was still OK (on device with
"dosfsck -n /dev/mmcblk0p1" run as root, or from the PC after connecting the
USB cable and selecting "Mass storage" mode).  If it's not OK, repair it with
the PC.  We can then discount the MyDocs corruption issue as a bricking reason.



[1] For latter it's possible, but on average there would need to be at least
hundreds of HW reboots to have enough bad luck that e.g. Ext3 file system used
for /home/ gets corrupted despite the journaling, *while* its being written and
there's a HW reboot or similar issue[2].   On normal devices these are so rare
that this shouldn't happen.

MyDocs uses the FAT file system (for Windows/OSX compatibility reasons) which
can corrupt easily on HW reboots because FAT doesn't support journaling. 
However, that doesn't/shouldn't prevent boot and can be repaired from the PC.

[2] Btw. Some people think that journaled file systems save them on power loss.
 This is not completely true even for the file system metadata, let alone for
file content.  Newer cut power or take the battery out unless you really need
to.

This has happened for me three times in the eight days I've had the device.
Always 32wd_to in bootreason. Does not get up to pin code request, freezes in
balloons. I'll check that charging next time this happens.

Comment 5 Eero Tamminen 2009-11-27 13:29:49 UTC

(In reply to comment #4)
> This has happened for me three times in the eight days I've had the device.
> Always 32wd_to in bootreason. Does not get up to pin code request, freezes in
> balloons.

There are two such animations, I think you mean the first one.  This means
around time X server is started and /home/ is mounted.

When the device is rebooted by the HW watchdog, this means that the file
systems weren't properly unmounted and their journals need to be replayed at
mount time.  If there was a lot of unsaved data (say, from Tracker file
indexing), this may take quite a bit of time.

How long did you wait?  Several minutes?

If waiting more doesn't help, there's either some race condition in the startup
scripts that gets triggered due to the larger mount time, or some data needed
by the bootup process is corrupted.

*** This bug has been confirmed by popular vote. ***

(In reply to comment #4)
> This has happened for me three times in the eight days I've had the device.
> Always 32wd_to in bootreason. Does not get up to pin code request, freezes in
> balloons. I'll check that charging next time this happens.
> 

symptoms of mine are similar.

i waited about 5 minutes after the animation froze, will wait much longer if
the problem comes up again...

Happened again last night when idling, no apps in use. This time I left the
device in the first balloons state until battery run out, something like 10
hours, but it didn't help. With usb cable yellow charging led lights up but it
doesn't show up as device in the host even after removing battery, freezes in
the same first balloons state without usb logo.

third time the device turned to brick. didn't help keeping overnight at the
balloon state. had to reflash.

Comment 10 Eero Tamminen 2009-11-30 12:52:31 UTC

(In reply to comment #7)
>> This has happened for me three times in the eight days I've had the device.
>> Always 32wd_to in bootreason. Does not get up to pin code request, freezes
>> in balloons. I'll check that charging next time this happens.
> 
> symptoms of mine are similar.
> 
> i waited about 5 minutes after the animation froze, will wait much longer if
> the problem comes up again...

Few minutes should be enough if its just slow journal replay.

I'm suspecting there's some race condition + deadlock in startup that gets
triggered if mounting of the file systems is much slower due to file systems
needing recovery (caused by HW watchdog reboot).  Or after too many recovery
needing file system mounts, the file system just cannot be recovered & mounted
anymore.

If it's not possible to log into device e.g. through SSH, the device needs
direct inspection (also for the 32wd_to reboots that are causing this issue).

I can send my unit back as it is if I get new in return after the device
becomes a brick next time.

(In reply to comment #8)
> Happened again last night when idling, no apps in use. This time I left the
> device in the first balloons state until battery run out, something like 10
> hours, but it didn't help. With usb cable yellow charging led lights up but it
> doesn't show up as device in the host even after removing battery, freezes in
> the same first balloons state without usb logo.
> 

Waiting until battery ran out was a bad idea, I needed to loan another battery
for flashing. So it seems that even though yellow led lights up it doesn't
really charge. Dosfsck didn't report anything wrong with /dev/mmcblk0p1.

My device bricked last night after "random reboot". It happened just like it is
described in earlier messages. Booting stops to first loading screen when the
second balloon from left is biggest.

Sent it back to Nokia today.

Hi,

i have the same problem, random reboots all the time (32wd_to). yesterday i was
downloading an app. -> random reboot -> now my n900 doesn't boot anymore..
hangs @ bootscreen with the five points second from the left is bigger.. :(
don't know what to do now... 

best regards from austria.

(In reply to comment #14)
> Hi,
> 
> i have the same problem, random reboots all the time (32wd_to). yesterday i was
> downloading an app. -> random reboot -> now my n900 doesn't boot anymore..
> hangs @ bootscreen with the five points second from the left is bigger.. :(
> don't know what to do now... 
> 
> best regards from austria.
> 

http://wiki.maemo.org/Updating_the_tablet_firmware

merci! my device is back online after emmc and firmware flash. BUT after
reconfigure my device like my wishes (sound, background,etc...) it reboots
again.

cat /proc/bootreasons

--> 32wd_to

any ideas ?

(In reply to comment #16)
> merci! my device is back online after emmc and firmware flash. BUT after
> reconfigure my device like my wishes (sound, background,etc...) it reboots
> again.
> 
> cat /proc/bootreasons
> 
> --> 32wd_to
> 
> any ideas ?
> 
try to get replacing device. (and see bug no. 6334)

Comment 18 Andre Klapper 2009-12-07 22:03:42 UTC

(In reply to comment #16)
> any ideas ?

See dependency bug 6334.
As long as bug 6334 is not fixed this issue here will also occur...
Nokia is working on it. :-/

(In reply to comment #18)
> (In reply to comment #16)
> > any ideas ?
> 
> See dependency bug 6334.
> As long as bug 6334 is not fixed this issue here will also occur...
> Nokia is working on it. :-/
> 

I also have similar issue
Can  you confirm that there will be a fix for this soon? , or should I send
back the device? I mean lot of people are not getting this bug, so is that a
specific hardware problem?

(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #16)
> > > any ideas ?
> > 
> > See dependency bug 6334.
> > As long as bug 6334 is not fixed this issue here will also occur...
> > Nokia is working on it. :-/
> > 
> 
> I also have similar issue
> Can  you confirm that there will be a fix for this soon? , or should I send
> back the device? I mean lot of people are not getting this bug, so is that a
> specific hardware problem?
> 

I'd say that send back device. But I can say for certain only after 2 weeks,
just took my device to service at monday and it was said to last 2 weeks.

Will report both to this and 6334 when I get answers from nokia service.

Created an attachment (id=1712) [details]
kernel with enabled framebuffer console

Could you please someone with bricked device try load this kernel?

It has enabled framebuffer console, so you should see boot messages directly on
screen and maybe you will see the reason why it stopped booting.

To load kernel please use flasher utility:
flasher -l -b -k zImage

For more information how to use flasher check this wiki page:
http://wiki.maemo.org/Flasher

(In reply to comment #21)
> Created an attachment (id=1712) [details] [details]
> kernel with enabled framebuffer console
> 
> Could you please someone with bricked device try load this kernel?
> 
> It has enabled framebuffer console, so you should see boot messages directly on
> screen and maybe you will see the reason why it stopped booting.

Enables framebuffer but all module loads fail with "disagrees about version of
symbol struct_module". Freezes in "Cannot create /sys" and after a while
reboots which it doesn't do with normal kernel. Could you also provide file
system image with modules for this kernel? Or framebuffer enabled kernel for
1.2009.42-11 image.

Seems like root partition gets corrupted as I was able to recover my device
with only flashing the rootfs.

I seem to have run into this same problem.  My device failed to wake up, and
unlike the previous random reboots (bug 6334) it didn't come back up.  It
didn't respond to any buttons at all.

I tried taking out the battery, waiting a bit, and putting it back in.  This
then brought the device to a state where the power button worked; it made the
blue light fade in and then the Nokia logo appeared with a white background. 
This then switched to the five white dots on a black background, which animated
for a while and then froze.  If I take out the battery and put it back in, the
same thing happens.

If I put the battery in while plugged up to USB, the device does go into
flashing mode, so I can try to recover it that way.  However, before doing so,
I want to find out if I can gather any useful information from the device in
its non-functional state that might help debug the problem so it won't happen
again.

I can confirm that flashing the rootfs alone seems to fix this problem.  I
downloaded the latest US firmware image, used flasher to unpack the FIASCO
image, flashed rootfs.jffs2, and the device now boots (to the first-time boot
screen, sigh).

Furthermore, flashing just the rootfs seems to have preserved most of my
settings, with the exception of installed/removed packages, and my wifi
configuration.

(In reply to comment #25)
> I can confirm that flashing the rootfs alone seems to fix this problem.  I
> downloaded the latest US firmware image, used flasher to unpack the FIASCO
> image, flashed rootfs.jffs2, and the device now boots (to the first-time boot
> screen, sigh).

Just to clarify, flashing the rootfs made the N900 boot again, but it still
randomly reboots as in bug 6334.

Would the device still randomly reboot if you do NOT have any apps from devel?
The only app from devel I have is haze, I have only experience one random
reboot so far.

Try using the device without any apps from devel.

(In reply to comment #28)
> Would the device still randomly reboot if you do NOT have any apps from devel?
> The only app from devel I have is haze, I have only experience one random
> reboot so far.
> 
> Try using the device without any apps from devel.

At this point, it seems very clear that the device can randomly reboot without
any additional apps.  Furthermore, apps shouldn't matter in the case of
hardware watchdog reboots (32wd_to).  In any case, see bug 6334 for the causes
of the reboots; this bug addresses the possibility of random reboots breaking
the device to the point where it needs reflashing.

Just had the same problem again.

I find it somewhat notable that my wedged N900 also consistently freezes at the
second dot from the left.  Either this animation always consistently takes the
same amount of time and the hang consistently takes the same amount of time
from startup, or the animation actually has some correlation to the steps taken
in the boot process and the boot process always hangs at the same step.

(In reply to comment #30)
> Just had the same problem again.
> 
> I find it somewhat notable that my wedged N900 also consistently freezes at the
> second dot from the left.  Either this animation always consistently takes the
> same amount of time and the hang consistently takes the same amount of time
> from startup, or the animation actually has some correlation to the steps taken
> in the boot process and the boot process always hangs at the same step.
> 

I can confirm this fully.

Comment 32 Eero Tamminen 2009-12-15 12:23:06 UTC

(In reply to comment #30)
> I find it somewhat notable that my wedged N900 also consistently freezes at
> the second dot from the left.  Either this animation always consistently takes
> the same amount of time and the hang consistently takes the same amount of
> time from startup, or the animation actually has some correlation to the
> steps taken in the boot process and the boot process always hangs at
> the same step.

From couple of the devices received (not sure whether they were for this bug),
it seems that it's actually possible also for the rootfs (UBIFS) file system to
get corrupted. UBIFS has gone through extensive automated power-cut-off
testing, according to which this "shouldn't" happen.  But I guess there's some
specific condition for this issue which cannot be triggered with automated
testing and which happens only when the device is being heavily used and then
HW reboots the device.

I'm a bit weary to go into all the details, but before reflashing your device,
try this:

sudo ./flasher-3.5 --enable-rd-mode

And reboot.

Some fotos here:
http://www.freemoe.org/users/jebba/MALF/

And in bug #7019

sudo ./flasher-3.5 --enable-rd-mode

With this, I was able to recover my device *WITHOUT REFLASHING*. (It also
showed
that it wasn't a full / filesystem that kept my system from booting.)

Sorry for the noise, but I was prodded to add:

Note to children playing at home: DO NOT LEAVE YOUR SYSTEM IN R&D MODE. It will
cause weird side effects (such as making your keyboard flash), so you should
disable it. To disable it run:

sudo ./flasher-3.5 --disable-rd-mode

If you don't have sudo set up, just run the command as root. Note this is a
GNU/Linux command, I'm not sure about other OSes.

In sum: I had a bricked system, I put it in R&D mode, I booted up in R&D mode
fine, I then put the system in Production mode and booted up fine again without
the need for any reflashing or data loss.

Comment 35 Eero Tamminen 2009-12-16 11:51:07 UTC

(In reply to comment #34)
> Note to children playing at home: DO NOT LEAVE YOUR SYSTEM IN R&D MODE.

Main reason for this is skipping of certain battery related checks in RD-mode.


> It will cause weird side effects (such as making your keyboard flash),

This is an indication that the device didn't enter the sleep state, something
is keeping it active although screen is blanked.  If the device is not doing
anything for you, it's a _potential_ use-time issue (some process or driver
waking up when it wouldn't need to).


> In sum: I had a bricked system, I put it in R&D mode, I booted up in R&D
> mode fine, I then put the system in Production mode and booted up fine
> again without the need for any reflashing or data loss.

Thanks, this is very interesting.  It would indicate that the issue could be
related either to bootup timings or whatever rd-mode does.

Were the 32wd_to (HW watchdog) reboots also the reason why your device ended in
non-bootable state?


(If yes, Andre, could you forward this to internal BTS?)

Comment 36 Eero Tamminen 2009-12-16 12:48:40 UTC

Thanks to the information provided in bug 7019, I found the issue (nearly same
thing as what N800 bug 957 was about).

The reason why RD-mode helps is that it ignores the max reboot count check and
allows device to reboot even when that (50 successive reboot) limit is
exceeded.  But the max reboot count should be ignored whenever device is booted
up normally and taken into account only on abnormal boots.

Before a fix to this bug is delivered, please make sure to turn off the device
(without charger) and back on before it gets rebooted 50 many in a succession. 
Turning the device on and off will clear the reboot count counter.

Perhaps that's why people that get "random reboots" also get "bricks": they are
more likely to be rebooting and incrementing the counter.

That said, I would be very surprised if I really had rebooted 50 times without
powering off as I do power off occasionally and don't reboot *that* often.

Thx for clarification of the cause. :)

(In reply to comment #36)
> Thanks to the information provided in bug 7019, I found the issue (nearly same
> thing as what N800 bug 957 was about).
> 
> The reason why RD-mode helps is that it ignores the max reboot count check and
> allows device to reboot even when that (50 successive reboot) limit is
> exceeded.  But the max reboot count should be ignored whenever device is booted
> up normally and taken into account only on abnormal boots.
> 
> Before a fix to this bug is delivered, please make sure to turn off the device
> (without charger) and back on before it gets rebooted 50 many in a succession. 
> Turning the device on and off will clear the reboot count counter.

Awesome, thank you for tracking this down!  This should make bug 6334 a lot
less problematic.

Given that I pretty much never turned my device off with the power button, and
given the timing of the two times the device got into the unbootable state, I
can easily believe that each such unbootable state occurred after 50
consecutive 32wd_to reboots.

Comment 39 Eero Tamminen 2009-12-16 19:16:37 UTC

(In reply to comment #37)
> Perhaps that's why people that get "random reboots" also get "bricks":
> they are more likely to be rebooting and incrementing the counter.
> 
> That said, I would be very surprised if I really had rebooted 50 times
> without powering off as I do power off occasionally and don't reboot
> *that* often.

After testing this (just with "killall Xorg"), it seems that the counter is for
some reason increased by 3 on every reboot.  I.e. it's enough to get 17
reboots.


The issue in this bug happens only when device is left "frozen" at bootup
instead of being correctly shutdown.

The root cause appears to be that when we during Fremantle development switched
to Upstart, it didn't anymore provide shutdown runlevel (runlevel is now a
dummy script) so that the device would have been correctly powered off when max
reboot count is reached (as it did earlier).

To prevent that issue, power users could probably quickfix /sbin/preinit script
with something like this:
                        echo_g "Houston, we have a problem, powering off..."
+                       sleep 10
+                       poweroff
                        def_runlevel=0

(beware: messing up the file update may prevent boots in general.)

The updated version of getbootstate package & binary will have also some other
improvements (in testing currently), but it's assumed that above should prevent
the device from freezing when max reboot count is reached (testing that takes
some time, without RD mode getting device to reboot 17 times is slow).

To clarify:

Hitting the power button and selecting "Turn off" ("Apagar" in Spanish, not
sure exactly what it says in English) and having the system shut down with the
power cable unplugged should avoid this bug, correct?

I posted about this (and linked to this bug) to t.m.o to warn users so they
could avoid bricking, and the question is coming up:

http://talk.maemo.org/showthread.php?t=37431

Also, the debrick without reflashing thread is here, fwiw:
http://talk.maemo.org/showthread.php?t=37420

And by the "getbootstate...in testing now" you mean internal Nokia testing, not
extras-testing, correct? Cuz I don't see it.

Also also, Summary should be changed from 50 reboots to 17 reboots, but I don't
have permission

(In reply to comment #40)
> Also also, Summary should be changed from 50 reboots to 17 reboots, but I don't
> have permission

Done.

Comment 42 Eero Tamminen 2009-12-17 19:17:57 UTC

I found one more way to get the device working again when the reason is max
reboot count:
- take battery out
- insert USB cable (to boot device with charging boot reason)
- insert battery & put back cover back
- remove USB cable

This might be used if one for some reason cannot use the flasher.


(In reply to comment #40)
> Hitting the power button and selecting "Turn off" ("Apagar" in Spanish, not
> sure exactly what it says in English) and having the system shut down with the
> power cable unplugged should avoid this bug, correct?

Correct.


> I posted about this (and linked to this bug) to t.m.o to warn users so they
> could avoid bricking, and the question is coming up:
> 
> http://talk.maemo.org/showthread.php?t=37431
> 
> Also, the debrick without reflashing thread is here, fwiw:
> http://talk.maemo.org/showthread.php?t=37420

Thanks!


> And by the "getbootstate...in testing now" you mean internal Nokia testing,
> not extras-testing,

Right.

N900, 2 days old, latest firmware

First day, kept rebooting randomly. Rally no pattern.
Got bricked after a while, freezing at second balloon.

Second day, read bugs and forums. Debricked without reflashing. Used flasher3.5
to turn on and off R&D. That did the trick.

Fully charged seemed to be more stable... but later became unstable and started
rebooting randomly again.

I left it the whole night on the power outlet, doing nothing else but laying on
the night table.

This morning, third day, I found it frozen. Turning off and on (after removing
the battery temporally) it stops again at the second balloon.

Very annoying, a new and expensive gadget that is totally useless.
Should I return the device or leave it in a drawer and wait for a software
update?

oh yeah, bootreasons: 32wd_to

Comment 44 Andre Klapper 2009-12-21 12:47:11 UTC

(In reply to comment #43)
> Very annoying, a new and expensive gadget that is totally useless.
> Should I return the device or leave it in a drawer and wait for a software
> update?

Nothing to be discussed here as this is a technical bugtracker and not a forum.
--> http://talk.maemo.org . Thanks.

Comment 45 Eero Tamminen 2009-12-21 13:43:32 UTC

In case somebody's not following bug 6334...  We have now an internal fix for
the 32wd_to reboots in testing which seems to be fixing those kind of reboots
(for that subset of devices where they appear).  It will most likely take
several weeks of testing until the next public release will be available
though.

In the meanwhile, to verify whether that fix should work for you, adventurous
power users can (as root) change the "enable_off_mode" value in /etc/pmconfig
from "1" to "0" and reboot.  This will completely ruin your device idle
use-time (idle device battery doesn't last much longer than device with
constant & active use), but if that change rids you of the reboots, then a fix
for those reboots (without the use-time impact) is coming.

Comment 46 Andre Klapper 2009-12-28 13:26:18 UTC

This has been fixed in package
getbootstate 1.0.38+0m5
which is part of the internal build version
2.2009.51-1
(Note: 2009 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

i had the same issue and I tought it was fixed editing pcmodule. I've used the
device all day without problems but now it started to reboot again. I've
checked that pcmodule is still correct. what information do you need?


(In reply to comment #46)
> This has been fixed in package
> getbootstate 1.0.38+0m5
> which is part of the internal build version
> 2.2009.51-1
> (Note: 2009 is the year, and the number after is the week.)
> 
> A future public update released with the year/week later than this internal
> build version will include the fix. (This is not always already the next public
> update.)
> Please verify that this new version fixes the bug by marking this bug report as
> VERIFIED after the public update has been released and if you have some time.
> 
> 
> To answer popular followup questions:
>  * Nokia does not announce release dates of public updates in advance.
>  * There is currently no access to these internal, non-public build versions.
>    A Brainstorm proposal to change this exists at
> http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
>

sorry. I mean editing pmconfig and rebooting manually. If the solution proposed
 for this bug is this, the problem still remains


(In reply to comment #47)
> i had the same issue and I tought it was fixed editing pcmodule. I've used the
> device all day without problems but now it started to reboot again. I've
> checked that pcmodule is still correct. what information do you need?
> 
> 
> (In reply to comment #46)
> > This has been fixed in package
> > getbootstate 1.0.38+0m5
> > which is part of the internal build version
> > 2.2009.51-1
> > (Note: 2009 is the year, and the number after is the week.)
> > 
> > A future public update released with the year/week later than this internal
> > build version will include the fix. (This is not always already the next public
> > update.)
> > Please verify that this new version fixes the bug by marking this bug report as
> > VERIFIED after the public update has been released and if you have some time.
> > 
> > 
> > To answer popular followup questions:
> >  * Nokia does not announce release dates of public updates in advance.
> >  * There is currently no access to these internal, non-public build versions.
> >    A Brainstorm proposal to change this exists at
> > http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
> > 
>

Comment 49 Andre Klapper 2010-01-02 01:06:03 UTC

guillem serra: Please remove unnecessary quotes of former comments before
commenting and avoid answering above the quote. Thanks.

the random reboot happened again and the bootreason is still the same 32wd_to.
I've checked pmconfig and enable_off_mode remains in 0. I was watching photos
when it happened. connected with wlan and with almost flat battery. I was
working all day without problems.

Comment 51 Andre Klapper 2010-01-02 18:02:20 UTC

(In reply to comment #50)
> the random reboot happened again and the bootreason is still the same 32wd_to

That's bug 6334. This report is only about the device not starting anymore.

Comment 52 Andre Klapper 2010-01-14 12:30:04 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

I was able to reboot ("Switch off!" with power plugged in) and come back OK
with a boot count of 51:

~ $ cat /var/lib/dsme/boot_count
51

I have boot_menu installed and I saw it flash something about MALF. It then did
another reboot and all came up fine:

~ $ cat /var/lib/dsme/boot_count
3

So it appears it isn't "bricking" after bootcount goes above 50 anymore. I
didn't count how many times I rebooted, but I'd be surprised if it was really
50, so I think it may still be incrementing by 3 or similar.

Comment 54 Eero Tamminen 2010-01-25 10:37:33 UTC

(In reply to comment #53)
> So it appears it isn't "bricking" after bootcount goes above 50 anymore.

Thanks for verifying!


> I didn't count how many times I rebooted, but I'd be surprised if it was
> really 50, so I think it may still be incrementing by 3 or similar.

There was no fix to increments happening by 3 (it's not incremented by 3 by
getbootstate, something else is also incrementing it, but as it's consistent,
there's no need to fix it for Fremantle).

(In reply to comment #42)
> I found one more way to get the device working again when the reason is max
> reboot count:
> - take battery out
> - insert USB cable (to boot device with charging boot reason)
> - insert battery & put back cover back
> - remove USB cable
> 
> This might be used if one for some reason cannot use the flasher.

Eero Tamminen, could you detail more on the process?

When inserting the USB cable, is the other end of the USB cable connected to a
PC?

When putting back battery & back cover, is the USB cable still attached to the
PC? (I'm kind of worried about that)

What happens after you do all these steps? Does N900 boot up normally and the
boot count is reset? (so we can upgrade firmware normally via OTA/SSU)

Thank you.

Comment 56 Eero Tamminen 2010-04-29 16:56:27 UTC

(In reply to comment #55)
> (In reply to comment #42)
> > I found one more way to get the device working again when the reason is max
> > reboot count:
> > - take battery out
> > - insert USB cable (to boot device with charging boot reason)
> > - insert battery & put back cover back
> > - remove USB cable
> > 
> > This might be used if one for some reason cannot use the flasher.
> 
> Eero Tamminen, could you detail more on the process?
> 
> When inserting the USB cable, is the other end of the USB cable connected to a
> PC?

Non-connected cables rarely do anything... :-)


> When putting back battery & back cover, is the USB cable still attached to the
> PC? (I'm kind of worried about that)

Then you'd better to use the charger.


> What happens after you do all these steps? Does N900 boot up normally and the
> boot count is reset?

It was over four months ago.  I don't remember whether the device needed
afterwards to be powered off and then restarted, but at least it started booted
 fine (boot count was reseted).


> (so we can upgrade firmware normally via OTA/SSU)

Just remember to backup your data before OTA/SSU.  If you have a device with an
old release which is booting frequently... Extra reboot(s) in middle of SSU
might cause the SSU to fail.  Then you probably need to reflash the device any
way.

(I myself reflash the device, SSU updated device uses a bit more memory than
reflashed one.  Backup&restore should work fine except maybe for some rare 3rd
party apps which don't tell backup how their data & config should be backed
up.)