maemo.org Bugzilla – Bug 6350
getbootstate bricks the device after 17 reboots if there are no normal boots in between them
Last modified: 2010-04-29 16:56:27 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: (Settings > General > About product) 42-11 EXACT STEPS LEADING TO PROBLEM: wait for random reboot EXPECTED OUTCOME: device reboots ACTUAL OUTCOME: device becomes bricked REPRODUCIBILITY: (always, less than 1/10, 5/10, 9/10) 2 times since 23.11.2009 EXTRA SOFTWARE INSTALLED: plugin-butterfly, some extras apps (<10) OTHER COMMENTS: nothing more to say. lost contacts etc again.... User-Agent: Mozilla/5.0 (X11; U; Linux armv7l; fi-FI; rv:1.9.2a1pre) Gecko/20090928 Firefox/3.5 Maemo Browser 1.4.1.21 RX-51 N900
"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.
> 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.
(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.
(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)
(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.
(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.
(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?)
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.
(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.
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
(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.
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.
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/ > > >
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.
(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.
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.
(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.
(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.)