maemo.org Bugzilla – Bug 6334
random but frequent HW watchdog reboots (/proc/bootreason contains "32wd_to") when returning from off_mode
Last modified: 2010-10-30 17:23:04 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 2009.42-11 EXACT STEPS LEADING TO PROBLEM: anything EXPECTED OUTCOME: device works normally ACTUAL OUTCOME: device reboots REPRODUCIBILITY: randomly. from 1 to 10+ times per day. EXTRA SOFTWARE INSTALLED: doesn't seem to affect. OTHER COMMENTS: see url for further info. it includes lot more background info. in nutshell: gps usb wlan 3g mfe google imap those have no effect atleat for me. device reboots either those are on or off. it seems that reboots occur more often when surfing @web. 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
Created an attachment (id=1631) [details] output of 'top -b -d 10' from point xx.xx to reboot start @ the bottom. this most probably doesn't help at all...
*** This bug has been confirmed by popular vote. ***
Two random device reboots here so far. Bootreasons sw_rst and 32wd_to, both happened while browsing the web. Unable to reproduce. ~ $ cat /var/lib/dsme/stats/lifeguard_resets /usr/bin/Xorg -logfile /tmp/Xorg.0.log -logverbose 1 -n: 1 ~ $ cat /var/lib/dsme/stats/lifeguard_restarts /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1
Rebooted also when opening the applications menu, writing an sms, changing the apn, update weather forecast, use dmesg on the terminal. The reboot is random and happens in different situations each time. my /var/lib/dsme/stats/lifeguard_restarts contains: /usr/bin/ohm-session-agent: 1 /usr/bin/hildon-desktop: 1 /proc/bootreason contains 32wd_to each time
Well done I found somes bodys with my same problem. I have every time a random reboot in differente situation, in the xtern, on web ... If you need some log I can give. Duto
Got same problem. With high usage it might even reboot every 5 min. Fresh N900 polish language version. No additional software installed.
My N900 after another reboot doesen't see the sim card anymore. Sending in back in RMA.
had reboot twice in a row when uploading hermes crash (python) dump with crash-reporter. I allready thought I found core reason but no, third try to upload went with no problems. Could this be connected to network Tx?!? Has anyone got the device to reboot with offline mode?
Hi Eero, any ideas how to track this down further, and which internal component applies for this? System Analysis? Also, the question to all reporters here is: Can you please list which 3rd party software you have installed, as it always might be the case that this is not triggered by official Nokia software? Maybe we can find some patterns...
Also, does everybody has "Crash Reporter" installed? Don't know if it also works for reboots, but might be worth a try...
yes, crash-reporter prompts to send crash reports after every crash with right settings. btw it is getting worse for me: my device was bricked 3 reboots (20min?) ago and I needed to reflash... fcking great!
added a bug rebort for bricking: https://bugs.maemo.org/show_bug.cgi?id=6350
I had at least two reboots when I didn' install a thing, straight from reflash. now i have only conboy installed and two reboots has occurred.
(In reply to comment #13) > I had at least two reboots when I didn' install a thing, straight from reflash. > > now i have only conboy installed and two reboots has occurred. > I also have now device only with factory made stuff. I was forced to use NSU because RSS reader stopped responding totally..and doesn't work even after I've installed fw again. Anyway.. I still have those reboots with "fresh" fw install. It can happen anytime in any situation. Few minutes ago I took my phone from a table and slided it open and it rebooted. Usually it happens like that or some seconds later. It can happen with or without battery charger, no difference. It's been like this right out of the box. I think first reboot happened already couple of minutes after I turned it on 1st time. Can't reproduce it as you all might know. It happens in all situations.
one possibility could be the ambient light sensor. how can I disable it? just got reboot only 5 seconds after keyboard light was shut off (moved the device so that it faced straight ceiling lamp). system froze almost immediately when kb went black.
(In reply to comment #15) > one possibility could be the ambient light sensor. how can I disable it? just > got reboot only 5 seconds after keyboard light was shut off (moved the device > so that it faced straight ceiling lamp). system froze almost immediately when > kb went black. > I got similar result when I tried it, used another phones led light. Trying to reproduce it now.
no luck with light sensor. crashed soon after i stopped trying with flaslight, normal room light and thumb over sensor over and over again plus general device usage at the same time. so light sensor is no go. next one will be struggling with OSK and wait if device reboots and try something else or find a solution to the problem.
I've just had this device, I was really happy at first...but in the 2 hours I've had it in my hand, it crashed at least 7 times (I'm not joking!). It kinda makes me think: if it was held up for so much time for "testing", how come this wasn't noticed? I understand that some bugs may slip, but this is making it somehow unusable! =( Kinda sucks when they say "open as many applications as you want" when it keeps restarting! =( Please solve this, I hope it's something a quick SW update can fix! Please please please! =(
(In reply to comment #18) > I've just had this device, I was really happy at first...but in the 2 hours > I've had it in my hand, it crashed at least 7 times (I'm not joking!). It kinda > makes me think: if it was held up for so much time for "testing", how come this > wasn't noticed? I understand that some bugs may slip, but this is making it > somehow unusable! =( Kinda sucks when they say "open as many applications as > you want" when it keeps restarting! =( Please solve this, I hope it's something > a quick SW update can fix! Please please please! =( > this doesnt help at all, so please go elsewhere. we others are trying to find the cause and then you come btching here... if it is important and you have nothing else to say, just vote without commenting. ant back to business: crashed when using onscreen keyboard only. so back to square one. had one thought in the morning what to try next, I'll try to memorize it and if I remember, will come to report the results.
Btw. This is marked as occurring with 42-11. Is there somebody who's still using the pre-release from Maemo Summit, and if yes, does flashing the sales release (42-11) help? And if you did an SSU update[1] from the Maemo summit release to 42-11, does *flashing* the new release help? [1] SSU updating between public releases is tested extensive, not between/from/to pre-releases like the Maemo summit one. Also, if I've understood correctly, the current SSU cannot update everything (e.g. phone side), the one in next release can do more (first SSU update will be updated SSU functionality and the next SSU update is where the main part of fixes & updates come). If the reboot happens with pre-installed or flashed 42-11, the most important information is what this command outputs in XTerm: cat /proc/bootreason If the reboot reason is "sw_rst" (instead of "32wd_to"), please provide also output from this command: cat /var/lib/dsme/stats/* (i.e. which crucial system service going down needed device reboot.) (In reply to comment #3) > Two random device reboots here so far. Bootreasons sw_rst and 32wd_to, > both happened while browsing the web. Unable to reproduce. > > ~ $ cat /var/lib/dsme/stats/lifeguard_resets > /usr/bin/Xorg -logfile /tmp/Xorg.0.log -logverbose 1 -n: 1 This Xorg related sw_rst is most likely something we know about (hairy & very rare SGX 3D driver memory management issue) and should be fixed in the next release. If they continue after the next release, please provide us Xorg core-dumps with Crash reporter (they could be useful also before that). The 32wd_to (HW watchdog rebooting the device due to not it being updated) is more worrying. For 32wd_to reboots we need to know when exactly they occur: - After device goes to sleep (screen blanks etc)? - When device wakes / is woken up from sleep? - When device is being used? -> If yes, do the reboots happen also in offline mode? If (32wd_to) reboots happen only when NOT using offline mode, we need to know whether this happens only in some particular networking environment. I.e. if you for example have reboots at home, do they happen somewhere else (e.g. at work) where you use a different WLAN/phone access point (with potentially different power management etc settings). If they happen only with some specific access points, please file a separate bug about that and provide the exact model of that access point and whether you've changed any of its default settings (or device default connectivity settings). (In reply to comment #7) > My N900 after another reboot doesen't see the sim card anymore. > Sending in back in RMA. Does your SIM card work in some other phone? > Also, the question to all reporters here is: > Can you please list which 3rd party software you have installed, as it always > might be the case that this is not triggered by official Nokia software? This should be relevant only for the "sw_rst" cases (or if one installs Crash reporter, the crash reports will tell what packages and package versions are installed). If the reboots are of the "wd32_to" variety, then it "should" not be relevant. For those, we need the answers to the questions above.
I haven't experienced this on the N900 so far with either 41-10 or 42-12. For sw_rst cases some syslog output from just before the reboot wouldn't hurt: 1. Install sysklogd (see <http://wiki.maemo.org/Documentation/devtools/maemo5>). 2. Wait for a random reboot. 3. Copy /var/log/syslog to a PC. 4. Look for the last instance of "syslogd 1.5.0#5maemo7+0m5: restart." in the file. 5. Attach the previous n (make sure it includes the last 10-20" before the reboot) lines here, removing any sensitive information.
(In reply to comment #20) > If the reboot happens with pre-installed or flashed 42-11, the most important > information is what this command outputs in XTerm: > cat /proc/bootreason > > If the reboot reason is "sw_rst" (instead of "32wd_to"), please provide also > output from this command: > cat /var/lib/dsme/stats/* > > (i.e. which crucial system service going down needed device reboot.) > > > > This Xorg related sw_rst is most likely something we know about (hairy & very > rare SGX 3D driver memory management issue) and should be fixed in the next > release. > > If they continue after the next release, please provide us Xorg core-dumps with > Crash reporter (they could be useful also before that). > > > The 32wd_to (HW watchdog rebooting the device due to not it being updated) is > more worrying. > > For 32wd_to reboots we need to know when exactly they occur: > - After device goes to sleep (screen blanks etc)? > - When device wakes / is woken up from sleep? > - When device is being used? > -> If yes, do the reboots happen also in offline mode? > > If (32wd_to) reboots happen only when NOT using offline mode, we need to know > whether this happens only in some particular networking environment. > > > Also, the question to all reporters here is: > > Can you please list which 3rd party software you have installed, as it always > > might be the case that this is not triggered by official Nokia software? > > This should be relevant only for the "sw_rst" cases (or if one installs Crash > reporter, the crash reports will tell what packages and package versions are > installed). If the reboots are of the "wd32_to" variety, then it "should" not > be relevant. For those, we need the answers to the questions above. > I have a regular production device with 42-11 since the first boot. Had to reflash it with 42-11 again yesterday because wasn't able to boot again after a crash ... was just surfing on nokia shop and only that... Since reflashing haven't installed any third part software neither Mail for Exchange in order to see if was stable on its own. Unfortunately still not stable. cat /proc/bootreason always give me 32wd_to I noticed while crash happens in really different tasks like writing an sms, surfing or just leaving it waiting for display to light off, I've been able to reproduce it almost every time I went to terminal to check bootreason just after the reboot then left device open for one or 2 minutes and after touching the display with my thumbs it freezes and reboot. Another frequent reason of reboot for me its just wait for it to light off the display, it crash most of times! While intensive use doesn't lead it to reboot!?! At least not for me! Tried these cases connected to my home WLAN, connected to mobile broadband, and in offline mode too! Always same behaviour.
Created an attachment (id=1634) [details] output of ps aux with 19 second intervals from time tt:tt to crash there seems to be a bug in my rough script. instead of i in the description block there should have been time lapsed in seconds.
(In reply to comment #23) > Created an attachment (id=1634) [details] [details] > output of ps aux with 19 second intervals from time tt:tt to crash > > there seems to be a bug in my rough script. instead of i in the description > block there should have been time lapsed in seconds. > sorry 10 seconds, not 19. just installed syslogd and will upload the output after next reboot.
(In reply to comment #21) > For sw_rst cases some syslog output from just before the reboot wouldn't hurt: While syslog is useful for debugging application and e.g. connectivity issues, please don't recommend it for reboots, at least for normal users: - the part before reboot isn't usually saved in wd32_to reboots - usually has little info on the system processes (they don't spam syslog) which termination causes sw_rst, - can contains users' private information (like user names etc) and is by default added to crash reports in full, if present (this is configurable from Crash reporter control panel applet for _future_ uploads though) - and will with time fill the rootfs which will prevent the device from booting(!). Uninstalling syslog doesn't remove /var/log/syslog* - can cause also other logging processes to freeze if some process is spamming the syslog a lot Crash reporter core uploads are needed for sw_rst reboot cases and good use-case descriptions for the 32wd_to reboots.
i can attach the syslog if you want to see how my n900 changes cell tower. in other words: syslogd isn't helping at all....
(In reply to comment #25) > While syslog is useful for debugging application and e.g. connectivity issues, > please don't recommend it for reboots, at least for normal users: True, but I thought this is a serious enough issue to warrant it and did say for sw_rst cases only and to filter out sensitive data. > - usually has little info on the system processes (they don't spam syslog) > which termination causes sw_rst, In my case at least (on N810, bug 6206) it did point to bme. > - and will with time fill the rootfs which will prevent the device > from booting(!). Uninstalling syslog doesn't remove /var/log/syslog* True, bug 5749 or maybe just a cron job to cycle the log could help there. > Crash reporter core uploads are needed for sw_rst reboot cases Of course that assumes the process actually dumped core, which may not always be the case. But yeah, I agree that sysklogd shouldn't be suggested lightly. I'll try to avoid that in the future.
(In reply to comment #27) > > - usually has little info on the system processes (they don't spam syslog) > > which termination causes sw_rst, > > In my case at least (on N810, bug 6206) it did point to bme. That information should already be available from: cat /var/lib/dsme/stats/* ? >> Crash reporter core uploads are needed for sw_rst reboot cases > > Of course that assumes the process actually dumped core, which may > not always be the case. You mean processes that just exit() when they notice this issue? Yes, if the process then also logs something to syslog then it helps, but usually such programs (e.g. D-BUS, at least earlier) seem to be so stupid that they do logging (only) to console... :-)
1.2009.42-11 I had reboots last night that happened twice in a row while doing the same thing. I was connecting to the internet through an ad-hoc network via my laptop's wifi card and while Google Talk was auto-connecting (with location) it rebooted. It happened twice before I disabled the Google Talk auto-connect and then it did not reboot. I didn't have time to do more testing to confirm it a third time, but I will report later with that info. $ cat /proc/bootreason sw_rst $ cat /var/lib/dsme/stats/* /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/mafw-dbus-wrapper mafw-get-renderer: 1 /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1
During this workday I had the device on my desk. Connected to 3G (no dataconnection or wlan) only app which was running was mediaplayer. It ran without problems (music playing, screen off and so on) several hours until I took it in my hands and started to do something..went to x-terminal to check last boot reason which was power button. Pretty much after that it rebooted. Practically it was one minute after firing it up from "sleep". After that reboot the reason was 32wd_to. Next 4 hours it was again on desk playing music all fine until after the work day I took it to my hands and started to do something..practically went to apps menu and it rebooted. After the boot I went to check bootreason and it was 32wd_to. came back to desktop and it rebooted again. That circle went round 7 times, always the same reason. So everytime it could hold only about 1 minute after restart until new reboot happened. The device became quite useless so I used power button to reboot it myself. Now it's been working ok half an hour. "For 32wd_to reboots we need to know when exactly they occur:" "- After device goes to sleep (screen blanks etc)?" -never when it sleeps but the moment when the screen is shutting down is critical "- When device wakes / is woken up from sleep?" -often minute or half after that "- When device is being used?" -it very seldom or never reboots when it's under heavy usage. Situations above are critical ones "-> If yes, do the reboots happen also in offline mode?" -first minute after wakeup is critical even in offline mode
What are games like Chess and Marbles doing different than for example web browser? I can play about one quick chess game before it reboots but marbles makes it boot almost immediately. So between those 3 the browser stays up the longest time, then chess, and marbles. Are these 3 using hardware resources different compared to eachothers or something else? Can someone else try if you can get something similar out of it? Device is now totally flashed to factory settings without any added program or setting change and reboots are just happening more and more often.
I've just had my first reboot. I've been using it a lot since receiving it yesterday, and was listening to music and composing a mail at the time, a broswer window was open in the background. Not sure if it is relevant, but it was attempting to reconnect to WLAN just before the reboot. $ cat /proc/bootreason sw_rst $ cat /var/lib/dsme/stats/* /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/hildon-status-menu: 1 /usr/bin/mafw-dbus-wrapper mafw-gst-renderer: 1 /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/hildon-status-menu: 1
(In reply to comment #28) > (In reply to comment #27) > > > - usually has little info on the system processes (they don't spam syslog) > > > which termination causes sw_rst, > > > > In my case at least (on N810, bug 6206) it did point to bme. > > That information should already be available from: > cat /var/lib/dsme/stats/* > ? > > > >> Crash reporter core uploads are needed for sw_rst reboot cases > > > > Of course that assumes the process actually dumped core, which may > > not always be the case. > > You mean processes that just exit() when they notice this issue? Yes, if the > process then also logs something to syslog then it helps, but usually such > programs (e.g. D-BUS, at least earlier) seem to be so stupid that they do > logging (only) to console... :-) > What should be the reasons to don't consider this issue also due to an HW bug if many devices showed it when they were got fresh from the box (some guys reported to have had this issue with no new software installed and also with no SIM inserted) ? It seems more a HW timing problem, maybe due to memories or board layout.
(In reply to comment #33) > What should be the reasons to don't consider this issue also due to an HW bug > if many devices showed it when they were got fresh from the box (some guys > reported to have had this issue with no new software installed and also with no > SIM inserted) ? > It seems more a HW timing problem, maybe due to memories or board layout. > I'm sorry for the previous comment, it was only a comment to the rebooting problems relating to the N900 that many users are reporting. I think that it's not the correct place to post that.
Question: Does everyone having this issue installed the Foreca Weather widget installed? If yes try uninstalling it and post here if there's any difference.
Have reboots also with foreca uninstalled. But I am a) loosing my mind or b) seeing a faint connection with bug 6350 https://bugs.maemo.org/show_bug.cgi?id=6350 (random reboot bricks device) and foreca. And reboots occur probably less when foreca isn't installed. but uninstalling (or not installing after reflash) doesn't still fix the problem entirely. DISCLAIMER: this isn't objective at all.
I had reboots often when adding a contact info. Now it has rather stopped. My last reboot was on Image Viewer when I was too fast in switching menus.
(In reply to comment #36) > Have reboots also with foreca uninstalled. But I am a) loosing my mind or b) > seeing a faint connection with bug 6350 > https://bugs.maemo.org/show_bug.cgi?id=6350 (random reboot bricks device) and > foreca. > > And reboots occur probably less when foreca isn't installed. but uninstalling > (or not installing after reflash) doesn't still fix the problem entirely. > > DISCLAIMER: this isn't objective at all. > Unfortunately you're right. I was hoping because haven't had a reboot for hours but still occur this morning twice. Now, this is not the best place for writing this but I just hope someone at Nokia stuff will read it: You can't really think all this people with this bug will keep waiting for long this way and I can't really use this as my only phone if this is how it works. But even worse you can't give a "Nokia Care" service that replies me with a sort of auto-responder when I spend this amount of money in a device that still not working. Please think twice how to manage it with a global care and individual assistance or this can cost the company just too much. This is not a threat because I really hope this platform to go on but can't spend my time rebooting: I'd rather prefer a phone that's just able to send sms without crashing! REALLY SORRY for everyone for this comment, please forgive my vent but couldn't keep it quiet after this morning mail got from Nokia ""Care..."" (was my first, not I'm annoying) Sorry again
(In reply to comment #30) > "- When device wakes / is woken up from sleep?" > -often minute or half after that It freezes when you "wake it up" and after 1/2 min it reboots? (1/2 min is the HW watchdog timeout) If it's related to wakeup, it sounds like a problem in the device power management (there's both SW and HW related to that). It doesn't wake up properly and the device HW watchdog reboots it. (In reply to comment #31) > What are games like Chess and Marbles doing different than for example web > browser? I can play about one quick chess game before it reboots but marbles > makes it boot almost immediately. Marbles animation for the selected piece is constantly updating the screen, using libSDL. Browser does screen updates only for www-page animation, or when you're panning the page, or for progress bar (much more rarely). Is this reboot while using the device? Is this sw_rst instead of 32wd_to? And if yes, what /var/lib/dsme/stats/* files report? > Device is now totally flashed to factory settings without any added program or > setting change and reboots are just happening more and more often. If it's happening more and more often, the multiple 32wd_to HW watchdog reboots (i.e. ones done without unmounting the file systems cleanly like can be done with sw_rst SW watchdog reboots) may have caused (I guess /home Ext3) file system to become corrupted. (In reply to comment #32) > I've just had my first reboot. I've been using it a lot since receiving it > yesterday, and was listening to music and composing a mail at the time, a > broswer window was open in the background. Not sure if it is relevant, but it > was attempting to reconnect to WLAN just before the reboot. Did you have any other device radios (Bluetooth, GPS) active? > $ cat /proc/bootreason > sw_rst > > $ cat /var/lib/dsme/stats/* > /usr/bin/ohm-session-agent: 1 > /usr/sbin/browserd -d: 1 > /usr/bin/hildon-status-menu: 1 > /usr/bin/mafw-dbus-wrapper mafw-gst-renderer: 1 > /usr/bin/ohm-session-agent: 1 > /usr/sbin/browserd -d: 1 > /usr/bin/hildon-status-menu: 1 None of these seem relevant for the SW watchdog reset, they should be just restarted when they terminate. I suspect this sw_rst may have been due to a kernel oops. Could you do as root this: gzip -c /dev/mtd2 > mtd2.gz And attach the mtd2.gz file here? (mtd2 flash partition on N900 devices is used to store kernel oopses.)
(In reply to comment #39) > (In reply to comment #30) > > "- When device wakes / is woken up from sleep?" > > -often minute or half after that > > It freezes when you "wake it up" and after 1/2 min it reboots? > (1/2 min is the HW watchdog timeout) > > If it's related to wakeup, it sounds like a problem in the device power > management (there's both SW and HW related to that). It doesn't wake up > properly and the device HW watchdog reboots it. > Yes, it very often rebooted within the first minute since wakeup. If I did something quickly and locked the screen and the keys immediately after that it didn't reboot. (On saturday and sunday I was driving many hours with my car listening web radios and transmitted them to car radio and not a single reboot maybe because I only quickly changed channels etc and shut the screen immediately after.) > > (In reply to comment #31) > > What are games like Chess and Marbles doing different than for example web > > browser? I can play about one quick chess game before it reboots but marbles > > makes it boot almost immediately. > > Marbles animation for the selected piece is constantly updating the screen, > using libSDL. Browser does screen updates only for www-page animation, or when > you're panning the page, or for progress bar (much more rarely). > > Is this reboot while using the device? Is this sw_rst instead of 32wd_to? And > if yes, what /var/lib/dsme/stats/* files report? > Always 32wd_to > > > Device is now totally flashed to factory settings without any added program or > > setting change and reboots are just happening more and more often. > > If it's happening more and more often, the multiple 32wd_to HW watchdog reboots > (i.e. ones done without unmounting the file systems cleanly like can be done > with sw_rst SW watchdog reboots) may have caused (I guess /home Ext3) file > system to become corrupted. > > Yesterday it stopped working totally, just like is described in bug 6350. I sent it Back to Nokia (cycleon/vantaa) today if someone wants to take a look. Hoping to get a working one back because as a device it is great.
I ran top yesterday and I saw that usr/bin/osso-rss was using about 89% of CPU. strangely I wasn't using the rss reader, nor was the rss widget installed on the desktop. could this be something that causes a reboot? excuse me if this sounds dumb; I'm new to Linux and the N900 but i'd like to help narrowing down this bug. wiebz
You're right Massimiliano, you just said what all of us are kinda afraid to say but we're all thinking the same thing: it's been advertised as a great device for multitasking but how can we prove that if it reboots everytime?!?!? It's unbearable, I hold my phone in my hand hoping, wishing and praying that it won't switch off, but it always does when you least expect it. I hope a SW update will just get rid of this bug... (In reply to comment #38) > (In reply to comment #36) > > Have reboots also with foreca uninstalled. But I am a) loosing my mind or b) > > seeing a faint connection with bug 6350 > > https://bugs.maemo.org/show_bug.cgi?id=6350 (random reboot bricks device) and > > foreca. > > > > And reboots occur probably less when foreca isn't installed. but uninstalling > > (or not installing after reflash) doesn't still fix the problem entirely. > > > > DISCLAIMER: this isn't objective at all. > > > > Unfortunately you're right. I was hoping because haven't had a reboot for hours > but still occur this morning twice. > > Now, this is not the best place for writing this but I just hope someone at > Nokia stuff will read it: > You can't really think all this people with this bug will keep waiting for long > this way and I can't really use this as my only phone if this is how it works. > But even worse you can't give a "Nokia Care" service that replies me with a > sort of auto-responder when I spend this amount of money in a device that still > not working. > Please think twice how to manage it with a global care and individual > assistance or this can cost the company just too much. > This is not a threat because I really hope this platform to go on but can't > spend my time rebooting: I'd rather prefer a phone that's just able to send sms > without crashing! > > REALLY SORRY for everyone for this comment, please forgive my vent but couldn't > keep it quiet after this morning mail got from Nokia ""Care..."" (was my first, > not I'm annoying) > > Sorry again >
Created an attachment (id=1649) [details] gzipped /dev/mtd2
I had three reboots during reading and attaching mtd2 to this bug. Really hope this will help: Reboot 1: $ cat /proc/bootreason sw_rst ~ $ cat /var/lib/dsme/stats/* /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/syncd: 6 /usr/bin/hildon-status-menu: 2 /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/syncd: 6 /usr/bin/hildon-status-menu: 1 Reboot 2: MyDocs $ cat /proc/bootreason sw_rst ~/MyDocs $ cat /var/lib/dsme/stats/* /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/syncd: 6 /usr/bin/hildon-status-menu: 2 /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/syncd: 6 /usr/bin/hildon-status-menu: 1 ~/MyDocs $ Reboot 3: Nokia-N900-42-11:~# cat /proc/bootreason 32wd_to Nokia-N900-42-11:~# cat /var/lib/dsme/stats/* /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/syncd: 6 /usr/bin/hildon-status-menu: 2 /usr/bin/ohm-session-agent: 1 /usr/sbin/browserd -d: 1 /usr/bin/syncd: 6 /usr/bin/hildon-status-menu: 1
Created an attachment (id=1651) [details] mtd2.gz from Calendar crash and reboot When adding calendar entry it crashed to internal error and then device rebooted. Same 32wd_to reason as usual.
(In reply to comment #45) > Created an attachment (id=1651) [details] [details] > mtd2.gz from Calendar crash and reboot > > When adding calendar entry it crashed to internal error and then device > rebooted. Same 32wd_to reason as usual. > Forgot to add that when I used python script to log bme battery status every second device worked perfectly for five hours. Right after killing that script device started rebooting again. To me it seems like omap or some other chip cannot recover from sleep/idle state. Is there a way to see omap throttling or some other power saving status?
Now, after the last reboot this morning, my N900 is bricked: THANKS NOKIA, VERY NICE FOR £500! Now I don't know what to do and I hope I haven't lost all my data...again, THANKS NOKIA!
(In reply to comment #47) > Now, after the last reboot this morning, my N900 is bricked: THANKS NOKIA, VERY > NICE FOR £500! Now I don't know what to do and I hope I haven't lost all my > data...again, THANKS NOKIA! This is a bug tracker and not appropriate here. Either go to a forum for rants or please change your tone. More postings like this might make you get your account here disabled. For reflashing info: http://wiki.maemo.org/Updating_the_tablet_firmware
N900 arrived yesterday morning. Used it all day (calls, SMS and (open) WIFI). When I got back home I stuck a screen protector (mentioning this just in case it may interfere in some obscure way with the screen driver...) and configured the WPA2-PSK network. Also installed Vim and gainroot. From that moment I'm getting reboots constantly. I removed the screen protector and de-configured my home LAN. No luck. Reboot (almost?)always happens within the first minute of unlocking the device (probably sliding the keyboard open). Always getting 32wd_to as bootreason. Please let me know if I can help in any way. Thanks.
Can a screen protector cause this problems? Because I got it too.
(In reply to comment #50) > Can a screen protector cause this problems? > > Because I got it too. > Rather no. I have removed it before even putting a battery inside after I got phone and still had same problem. Now phone is bricked. (stuck on 5 dots). Sending phone to Nokia service.
Getting random reboots ever since I turned on my N900. Mainly after heavy use w/ browser, but almost always with browser open in background. Reboot reason: 32wd_to Are the ways to provide more info / crash reports?
Sorry for my previous comment, this bug is really stressing out. Anyway, I flashed it and noticed one thing: they've updated the firmwares. Well, they're the same BUT there used to be some kind of "wrong SW" online for 64-bit PCs. I've just flashed mine with the right one, did as it said, everything with admin permissions and it's now working like a charm and, to my surprise, no reboots yet! I'm now charging the battery to full (apparently flashing consumes quite a lot), I'll let you know if the reboot saga happens again.
(In reply to comment #41) > I ran top yesterday and I saw that usr/bin/osso-rss was using about 89% > of CPU. strangely I wasn't using the rss reader, nor was the rss widget > installed on the desktop. You may have the RSS feed refresh enabled. > could this be something that causes a reboot? It's nothing to do with this bug. (In reply to comment #43) > Created an attachment (id=1649) [details] [details] > gzipped /dev/mtd2 [101104.589904] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT ... [101104.590637] PC is at cpu_v7_switch_mm+0xc/0x28 ... [101104.590942] Process swapper (pid: 0, stack limit = 0xc03502e0) File system corruption? [103158.102447] Kernel panic - not syncing: Attempted to kill init! I hope you don't have RD-mode & serial console RD-flag enabled. without anything attached to the back of the device to ground the pins, enabling serial console can cause all kinds of funny effects (like reboots). (In reply to comment #45) > Created an attachment (id=1651) [details] [details] > mtd2.gz from Calendar crash and reboot > > When adding calendar entry it crashed to internal error and then device > rebooted. Same 32wd_to reason as usual. Kernel had once Oopsed to this: HASH_Create () from pvrsrvkm HASH_Insert_Extended () from pvrsrvkm HASH_Insert () from pvrsrvkm (SGX driver kernel side functionality in the composite manager process context.) Oops caused one reboot, but that might not have been the 32wd_to one (should be sw_rst, normally oops shouldn't freeze the device). We don't have this in our internal bug tracker, so I guess this particular oops isn't reproducible. (In reply to comment #46) > Forgot to add that when I used python script to log bme battery status every > second device worked perfectly for five hours. Right after killing that script > device started rebooting again. To me it seems like omap or some other chip > cannot recover from sleep/idle state. Is there a way to see omap throttling or > some other power saving status? See here: /sys/devices/system/cpu/cpu0/cpufreq/ /sys/power/ (It's not very safe to fiddle with these, especially the latter ones.)
Just wondering: would it have anything to do with the fact that we've got 4 desktops? I mean, I know the N900's got a massive RAM (well, massive compared to most phones out there) BUT probably it runs out of memory trying to keep not only the applications open BUT also the desktops and all the widgets and links and bookmarks in them...I don't know, just guessing... But I can confirm that it doesn't reboot when I'm ONLY listening to music UNLESS I do something "extraordinary" like sorting songs by artist (that usually makes it reboot)... but, as I said, I'm just guessing, looking at it from a user point of view...
(In reply to comment #54) > (In reply to comment #43) > > Created an attachment (id=1649) [details] [details] [details] > > gzipped /dev/mtd2 > > [101104.589904] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT > ... > [101104.590637] PC is at cpu_v7_switch_mm+0xc/0x28 > ... > [101104.590942] Process swapper (pid: 0, stack limit = 0xc03502e0) > > File system corruption? I'll try to run fsck on it. It could only be corrupted by random reboots because I never removed battery on running system nor did anything nasty to it. > [103158.102447] Kernel panic - not syncing: Attempted to kill init! > > I hope you don't have RD-mode & serial console RD-flag enabled. without > anything attached to the back of the device to ground the pins, enabling serial > console can cause all kinds of funny effects (like reboots). I did not flash my device so I don't think I have RD mode enabled. I'm a rather regular user - no hardware hacking here.
getting random reboots too. bootreason reports 32wd_to. happens randomly, sometimes during use sometimes after wake.
Was about set some alarms; rebooted, stayed on the phone with my girl for 45 minutes and right after hanging up; rebooted, updated app manager; rebooted, browsed maemo.org rebooted, made only one desktop active; rebooted, added widget and shortcuts; rebooted. extra software installed: nothing. MfE active just for calendar and contacts Gmail used from the built in, email client.
(In reply to comment #56) > > [101104.589904] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT > > ... > > [101104.590637] PC is at cpu_v7_switch_mm+0xc/0x28 > > > > File system corruption? This is actually in kernel code. After looking at the code asm instructions, don't see how there could be an undefined instruction (it's "isb"). Maybe the kernel oops logging functionality didn't work quite correctly at this point... :-/ Btw. Oops partition content is never cleared, *even* when the device is reflashed, newer oopses just overwrite older ones (they wrap at the end of this small partition). This is something to keep in mind if somebody looks into the logged oopses.
Maybe we should zero the contents of /dev/mtd2 and check if random reboots cause any writes into it? Unfortunately I won't have time until weekend to do it.
Reboot again: 32wd_to Two browser windows in background, sent sms, toggled screen off, received sms, toggled screen on, attempted to tap icon to bring up dashboard, no response, tap more, no responses, reboot.
(In reply to comment #61) > Reboot again: 32wd_to > > Two browser windows in background, sent sms, toggled screen off, received sms, > toggled screen on, attempted to tap icon to bring up dashboard, no response, > tap more, no responses, reboot. > More details: - After reboot incoming sms was not found in conversations. - Running AT&T SIM, no wi-fi, no bluetooth, no other installed apps
Just for your info. I've been running the device without the SIM card for some hours and it kept rebooting.
it is a bit ironic but it seems that when browsing talk.maemo.org, rate of reboots goes really high. no power saving etc, as soon as device has booted browse to thread you didnt finish and device will reboot again before you have finished again...
i getting random reboots on my n900 too. bootreason always reports 32wd_to. happens randomly. sometimes working stable up to 24 hours, but same time it can reboots 2-5 times in 1 hour sorry for my english
(In reply to comment #65) > i getting random reboots on my n900 too. > bootreason always reports 32wd_to. > happens randomly. Does it freeze first or does it reboot directly while being used? If latter, could you provide the file you can get running (as root): cat /dev/mtd2 > mtd2 ? (In reply to comment #63) > Just for your info. I've been running the device without the SIM > card for some hours and it kept rebooting. (In reply to comment #58) > Was about set some alarms; rebooted, > stayed on the phone with my girl for 45 minutes and right after hanging up; > rebooted, > updated app manager; rebooted, > browsed maemo.org rebooted, > made only one desktop active; rebooted, > added widget and shortcuts; rebooted. These comments are useless unless accompanied also with information requested in comment 20 (and comment 39). Could you provide that also if / when the reboot happens next? (Even better would be to check it for all the reboots to see whether they all are similar as the use-cases aren't similar.)
atleast my reboots are similar: device stops responding and after couple seconds screen goes black and the 5 balloons -animation comes up booting the device to homescreen without pin -request etc. 32wd_to is always the bootreason and /dev/mtd2 was a huge file full of emptiness so I cleared it and will attach it here if something appears there when booting.
(In reply to comment #67) > atleast my reboots are similar: device stops responding and after couple > seconds screen goes black and the 5 balloons -animation comes up booting the > device to homescreen without pin -request etc. > > 32wd_to is always the bootreason It appears my information on 1/2 min freeze needed for the HW watchdog to reboot the device was outdated (from Diablo). In Fremantle, the timeout is 14 secs and DSME thread kicks it every 12 secs. So, the device freeze triggering HW watchdog can be anything from 2 to 14 secs.
Created an attachment (id=1661) [details] output of /dev/mtd2 after two reboots
(In reply to comment #69) > Created an attachment (id=1661) [details] [details] > output of /dev/mtd2 after two reboots > sorry forgot to mention that bootreason was 32wd_to
(In reply to comment #66) > (In reply to comment #65) > > i getting random reboots on my n900 too. > > bootreason always reports 32wd_to. > > happens randomly. > > Does it freeze first or does it reboot directly while being used? > If latter, could you provide the file you can get running (as root): > cat /dev/mtd2 > mtd2 > ? yes, it reboot when it use, trying launch some app or surfing web - freeze 1-3 seconds, then occurs too as it is written to comment #67
Added internal bug number for freeze&reboot sometimes happening (in some devices) when the device is woken up from idle (idle here meaning CPU idle state, not screen blank etc). On an assumption that some number of the 32wd_to HW watchdog reboots are due to power management, maybe somebody having them (especially when waking up the device) could try disabling the CPU voltage & frequency scaling and see whether that helps significantly? It can be done by changing "ondemand" to "userspace" in "/etc/pmconfig" file and rebooting the device (without charger being connected). This will use a fixed CPU frequency which means that: - you have worse use-time - device is slightly slower Than with the "ondemand" scaling governor. You can see the frequency with: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq (AFAIK should be 500Mhz after this change) (In reply to comment #70) > (In reply to comment #69) > > Created an attachment (id=1661) [details] [details] [details] > > output of /dev/mtd2 after two reboots [ 152.196990] [669bd306] *pgd=00000000 [ 152.196990] Internal error: Oops: 5 [#1] PREEMPT ... [ 152.197814] [<c00b3e24>] (kmem_cache_alloc+0x0/0x84) from [<c020c440>] (sk_pr ot_alloc+0x2c/0x120) > sorry forgot to mention that bootreason was 32wd_to For both? (Oops should result in sw_rst)
Changing scaling_governor from "ondemand" to "userspace" did not help at least in my case. The frequency of reboots (about 1-5 in 10 minutes, during opening/closing/editing settings/applications) is the same. My unit is fresh out of the box, only rootsh installed to allow pmconfig-file to be edited. Checked with scaling_cur_freq: 500000, so "userspace" is the active setting. Reboot reason with my unit is always 32wd_to
(In reply to comment #73) > Changing scaling_governor from "ondemand" to "userspace" did not help at least > in my case. Same here, three reboots in fifteen minutes when testing this. Nothing in mtd2.
(In reply to comment #73) > Changing scaling_governor from "ondemand" to "userspace" did not > help at least in my case. ... > Reboot reason with my unit is always 32wd_to (In reply to comment #74) > Same here, three reboots in fifteen minutes when testing this. If these happened while using the device actively, could you keep the setting for a while and check whether there are still reboots also when the device is woken up from idling?
I have ordinary phone (not developers edition, but one bought from Nokia Online). It has polish language version and firmware 1.2009.42-11. I have ForecaWeather widget installed and active. It reboots with 32wd_to as result. The reboots happen when using WiFi in my home. Currently I have no possibility to check other WiFi access point. I had one reboot when phone was connected to WiFi but I was not transmitting any data - at that time I was removing many items from calendar (result of bad import of ICS file). All other reboots happened when using WiFi. The mostly happen when I am watching some short flash movie, for example at BBC pages. One reboot happened after about 20 minutes of conversation via Skype. Usually reboots happen about 15 to 20 minutes of web surfing (without breaks). If I make breaks (e.g. watch some pages for few minutes, read book for quarter, then again watch some pages) it takes more time to reboot. Two days ago I was experimenting. Changing WiFi settings to 10mW from 100mW did not help much. Changing power settings from maximum to medium also did not remove reboots. But after disabling WiFi power saving (in Advanced) I did not have reboot for about half an hour; however during that time battery level dropped for about 20-30% and top of device (where, according to manual, WiFi antenna is located) got rather warm. I was still able to touch it, but decided to turn WiFi power savings on again. During all resets the screen went very dark with Nokia logo, then five-points animation, then Nokia animation (with connecting hands and sound) then again five points, and normal desktop. Only once notification diode went white and it looked like normal cold start, with PIN question. I believe that at least in case of my device reboots are connected to WiFi - when I was not connected to the WiFi and was watching movie from the flash, I did not have reboot.
(In reply to comment #76) > It reboots with 32wd_to as result. The reboots happen when using WiFi in my > home. Can you provide (as root), the kernel oops logging partition content? cat /dev/mtd2 > mtd2 gzip mtd2
Created an attachment (id=1666) [details] mtd2 aftert few reboots I forget to mention one thing - I also installed Bounce Evolution and was playing 10-15 minutes - and n900 did not crash then.
I've also seen random crashes (about once a day) As far as I can tell, the common factors for my crashes have been: - Wifi is enabled. It doesn't seem to matter which Wifi point I'm connected to, it's happened both at home and work. - The device is charging - I've just recently touched the screen. From my last crash, the bootreason was 32wd_to (I've never seen a sw_rst bootreason) and cat /var/lib/dsme/stats/* gave: /usr/bin/syncd: 3 /usr/sbin/browserd -d: 1 /usr/bin/hildon-home: 1 /usr/bin/syncd: 3 /usr/sbin/browserd -d: 1 Any other information you'd like from my device? It's running 1.2009.42-11.002 and was purchased from Nokia just a few days ago.
for this last 2 days, i didnot visit maemo.org, and today i tried to visit the tmo and the phone rebooted 3 times in 1 hour while i was surfing talk.maemo.org
(In reply to comment #76) > I believe that at least in case of my device reboots are connected to WiFi - > when I was not connected to the WiFi and was watching movie from the flash, I > did not have reboot. Try chess game, sure way to reboot my device even without wlan or bluetooth.
Got my first random reboot today after 5 days having the phone. Wasn't doing anything, the device was locked, all the sudden I saw Nokia screen and realised it was rebooting. You can expect me using the device normally with nothing out of the ordinary.
For starters I'd like to state that I got the phone brand new from my operator on 4.12 and been actively using it since. The device started rebooting itself from time to time (about 2-10 times per hour depeding on use) right from the start. I didn't know about bootreason back then, but as the symptoms are clearly same as today, I imagine every single one would have been this "32wd_to" problem. I also had to reflash the eMMC yesterday because phone wouldn't start after one of these resets. Only flashing the firmware wasn't enough to get it running. The reason I'm writing here is that I *think* the problem has something to do with WLAN connection. The only time I've gotten more than 10minutes of usage out of the phone without rebooting was today when I went out for food. I surfed about half an hour on heavy web pages while walking around and sitting waiting for food. I've NEVER before got through a normal surfing session without a reboot. I didn't check for it but I'm pretty sure there were no WLAN's available through the whole time. As soon as I hit home, the device went mental. Same goes for if I go to work, which is in a mall with multiple WLAN's available. Craziest part of this is that for today I've had my WLAN disabled from the settings, and I've only been using the 3G connection. I have a feeling that the device is sniffing for WLAN connection even though I've deleted all the AP's and set the interval to 'never'. I tried to cat the mtd2 after reboot but it seems it's just full of emptiness. To investigate this further, is there any way to completely shut down the WLAN or is it genuinely off already? If it is, sorry for wrong hunch.
(In reply to comment #83) > For starters I'd like to state that I got the phone brand new from my operator > on 4.12 and been actively using it since. The device started rebooting itself > from time to time (about 2-10 times per hour depeding on use) right from the > start. I didn't know about bootreason back then, but as the symptoms are > clearly same as today, I imagine every single one would have been this > "32wd_to" problem. I also had to reflash the eMMC yesterday because phone > wouldn't start after one of these resets. Only flashing the firmware wasn't > enough to get it running. > > The reason I'm writing here is that I *think* the problem has something to do > with WLAN connection. The only time I've gotten more than 10minutes of usage > out of the phone without rebooting was today when I went out for food. I surfed > about half an hour on heavy web pages while walking around and sitting waiting > for food. I've NEVER before got through a normal surfing session without a > reboot. I didn't check for it but I'm pretty sure there were no WLAN's > available through the whole time. As soon as I hit home, the device went > mental. Same goes for if I go to work, which is in a mall with multiple WLAN's > available. > > Craziest part of this is that for today I've had my WLAN disabled from the > settings, and I've only been using the 3G connection. I have a feeling that the > device is sniffing for WLAN connection even though I've deleted all the AP's > and set the interval to 'never'. > > I tried to cat the mtd2 after reboot but it seems it's just full of emptiness. > > To investigate this further, is there any way to completely shut down the WLAN > or is it genuinely off already? If it is, sorry for wrong hunch. > I had just today a reboot when using 3g only to write an email. for me it seems that web browser & email app makes the reboots go wild. so it could be connected to network operations. all hunches are needed until some confirmation will be available. cat /proc/bootreason gives you the bootreason. and i've just tried to disable wlan by a) settings: network search off b) ifconfig wlan0 down lets see what happends.
(In reply to comment #84) > cat /proc/bootreason > gives you the bootreason. When you did cat /proc/bootreason on yours, what was the reason?
disabling wlan didn't help. crashed as usual when using web browser. So disabling wlan is a dead end atleast with my device. Unless disabling whole module does the trick. unable to remove wlan module so if somebody doesn't know how to do it I can't test that.
for me this bug seems only to appear when using battery power. whenever i am charging my phone no reboots occur or at least uptime is much much longer than when using the phone on battery. most of the time this bug appears on battery power when the phone is going to idle mode or waking up from idle. bootreason is always 32wd_to
(In reply to comment #85) > (In reply to comment #84) > > > cat /proc/bootreason > > gives you the bootreason. > > When you did cat /proc/bootreason on yours, what was the reason? > always 32wd_to
i will take a little bit back on my previous post. i took the phone off the charger for a little while and did not do anything with it. as soon as i got back home i put it back to charger and as soon as i woke it up from idle it rebooted. so. it seems it does not matter wheather i'm charging or not.
After reoccuring crashes (32wd_to) during the weekend my N900 was bricked today. I managed to get it back by reflashing (both 42-11 and eMMC), but the reboots still continue. I tested with offline-mode to try to see if wireless connections are the cause, but still managed to get couple 32wd_to reboots (maybe not as frequent). Also checked the FAT32 partition few times during the weekend, but no filesystem corruption found.
(In reply to comment #90) > After reoccuring crashes (32wd_to) during the weekend my N900 was bricked > today. I managed to get it back by reflashing (both 42-11 and eMMC), but the > reboots still continue. feel free then to vote bug 6350 https://bugs.maemo.org/show_bug.cgi?id=6350
Reboot just 10 minutes ago. I was using Zootube (downloading a video) and responding to a sms.
i've got my device three days ago. since then the device rebooted for a least 10 times a day. regardless of connection type, charging or whatever esoteric reason there might be observable and reported in this ticket. please, fix this annoying issue as soon as possible. (offtopic) looks like quality assurance has failed (again), or the device's hardware is defective on a large scale. i'm disappointed!! maybe it's time for some bad press to remind nokia of all the things they have done wrong with the N770, N800 and N810.
(In reply to comment #93) > (offtopic) > looks like quality assurance has failed (again), or the device's hardware is > defective on a large scale. i'm disappointed!! maybe it's time for some bad > press to remind nokia of all the things they have done wrong with the N770, > N800 and N810. > offtopic, it seems that 46 votes for this bug really makes this totally minor failure, could be for example within 6 sigma. and the rest who have to comment something like this, go ahead and visit: http://talk.maemo.org/showthread.php?t=35055 that is really good place for this offtopic here.
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 ------------------------------------------------------------ For 32wd_to reboots we need to know when exactly they occur: - After device goes to sleep (screen blanks etc)? - When device wakes / is woken up from sleep? - When device is being used? -> If yes, do the reboots happen also in offline mode? ------------------------------------------------------------ it mostly occur if you do somethin on your device like this: -)writing a sms - typing and typing and typing... short break for thinking.. 3 second freeze ->restart -)switching through the desktop, hold on for a second on one desktop ->3 second freeze & restart -)open terminal, go /proc, cat bootreasons, looked at it (1-3 seconds break) - 3 seconds freeze & restart i have a lot of example like this. what i want to say is, that even if you use the device full, surf web, writing somethin, etc.. and make no tinkbreak or whatever the device will not reboot. if you do a little bit here and a little bit there, wait, an go on.. uups device frozen, reboot. for my experience it is not necessary if the device is on offline or online mode, if it use a simcard or not. if you use status led, touchsensors, sounds, etc... or not. it really never mind. if you need any logfiles from me (32wd_to) i will give. but you have to say exactly where i find them, because i am no linux pro :) best regards from austria! ps: i thing device is great, so i will do my best to help you out with fixing this problem.
My N900 will no longer boot after the random reboots. Last one was during streaming internet radio over wi-fi. Where can I find instructions to 'reflash' the device?
(In reply to comment #96) > My N900 will no longer boot after the random reboots. Last one was during > streaming internet radio over wi-fi. Where can I find instructions to 'reflash' > the device? > http://wiki.maemo.org/Updating_the_firmware
FYI: sent my device to service today. (From Midare Jyväskylä, sent to the main service site at Finland I think) I hope I'm getting a new device and they send a replacement asap. But I've got a feeling that it is at least 2 weeks without the device...
-----------------------------(In reply to comment #72) > Added internal bug number for freeze&reboot sometimes happening (in some > devices) when the device is woken up from idle (idle here meaning CPU idle > state, not screen blank etc). > On an assumption that some number of the 32wd_to HW watchdog reboots are due to > power management, maybe somebody having them (especially when waking up the > device) could try disabling the CPU voltage & frequency scaling and see whether > that helps significantly? this helps definitly, thank you! no reboot since i changed this! ~ 4 hours ago. was doing the same stuff like befor, where my device reboots up to 10 times. i will check it until tomorow if it helps really, but for now it looks good! best regards & merci!
Changing ondemand to userspace in power management settings did not help me at all. The device rebooted at least twice within half an hour after changing the setting and rebooting device. I also checked that my cpu frequency was 500 so userspace mode was definitely on. also my /dev/mtd2 shows a whole bunch of emptiness after these reboots. (In reply to comment #99) > -----------------------------(In reply to comment #72) > > Added internal bug number for freeze&reboot sometimes happening (in some > > devices) when the device is woken up from idle (idle here meaning CPU idle > > state, not screen blank etc). > > On an assumption that some number of the 32wd_to HW watchdog reboots are due to > > power management, maybe somebody having them (especially when waking up the > > device) could try disabling the CPU voltage & frequency scaling and see whether > > that helps significantly? > > > this helps definitly, thank you! no reboot since i changed this! ~ 4 hours ago. > was doing the same stuff like befor, where my device reboots up to 10 times. > > i will check it until tomorow if it helps really, but for now it looks good! > > best regards & merci! >
Created an attachment (id=1684) [details] output of /dev/mtd2 after a reboot
Yesterday I experienced not a reboot but audio hardware glitch. I was using the n900 on the web for about 30 minutes and it didn't reboot. I went to the http://www.youtube.com/watch?v=W5scOcSKTuI&feature=player_embedded# I started the movie and switched to fullscreen. After about five minutes sound stopped playing and instead from speakers mechanical sound was appearing. The sound was very similar to sound that I was experiencing when I was programming SoundBlaster16 (it was long time ago) in DMA mode and my program crashed. It means that it sounded like the application that was providing sound card with data stopped responding and sound card was playing very short period that was present in the buffer. However my phone did not crashed nor rebooted. Browser crashed, window with question "Page not responding - should I close the window" appeared, but system had problems with killing browser window. I used on/off button to kill the browser by using "Kill current program". For the entire time this annoying sound was playing with rather high volume. When I tried to turn sound down by using software slider, it has not done anything. I have not checked lowering volume by the hardware key. I decided to switch off the phone. I pressed on/off key for few seconds, white notification light appeared, phone turned off and sound stopped. After few seconds I turned phone on, connected to the network and was able to watch few more pages. So it looks like YouTube flash crashed browser, it crashed audio subsystem but phone did not reboot. I am providing this report because the sound that was emitted was very similar to the sound that I was hearing just before previous reboots - but this time OS survived. As phone hasn't rebooted I am not attaching mtd2 - but I can do it if it is necessary.
(In reply to comment #102) > Yesterday I experienced not a reboot but audio hardware glitch. Probably unrelated.
.
I strongly believe this has to do with WLAN connectivity (at least in my case). After disabling automatic connection switching to WLAN, I've had no arbitrary reboots at all. Before that, the device rebooted >10 times during a day of heavy usage. I didn't check the boot reason for each boot but everytime I did, it was 32wd_to.
(In reply to comment #105) > I strongly believe this has to do with WLAN connectivity (at least in my case). > After disabling automatic connection switching to WLAN, I've had no arbitrary > reboots at all. Before that, the device rebooted >10 times during a day of > heavy usage. I didn't check the boot reason for each boot but everytime I did, > it was 32wd_to. > Try offline mode + chess. With my device shutting wlan off did help but didn't stop reboots, only made those appear less frequently.
(In reply to comment #106) > Try offline mode + chess. With my device shutting wlan off did help but didn't > stop reboots, only made those appear less frequently. Yes, that did the trick. After playing a couple of minutes, the device rebooted, with boot reason 32wd_to.
I get spontaneous reboots from watchdog. I've reproduced with and without gsm and wifi. I get crashes with just the stock firmware but more software seems to help crashing. Ironically just got a crash just after installing crash reporter ... I tried running the device in r&d with no-lifeguard but that didn't help, I still got watchdog reboots instead of lockups. Is that expectable or did I do something wrong ?
Created an attachment (id=1689) [details] enqueue_entity NULL pointers I've cleared mtd2 before doing some tests. Yesterday I had 3 reboots with sw_rst bootreason. All of them seems to be caused by NULL pointer in enqueue_entity (attaching mtd2 with all three stacktraces). There was one 32wd_to and this one did not leave any trace in mtd2.
(In reply to comment #99) > this helps definitly, thank you! no reboot since i changed this! ~ 4 hours > ago. was doing the same stuff like befor, where my device reboots up to 10 > times. > > i will check it until tomorow if it helps really, but for now it looks good! Thanks! This was yesterday, does it seem still to help? (In reply to comment #105) > I strongly believe this has to do with WLAN connectivity (at least in my > case). After disabling automatic connection switching to WLAN, I've had no > arbitrary reboots at all. Before that, the device rebooted >10 times during > a day of heavy usage. I didn't check the boot reason for each boot but > everytime I did, it was 32wd_to. Could you provide the /dev/mtd2 contents? I'd like to verify whether you got the same networking related oops as one of the above commenters. (In reply to comment #109) > Yesterday I had 3 reboots with sw_rst bootreason. All of them seems to be > caused by NULL pointer in enqueue_entity (attaching mtd2 with all three > stacktraces). There was one 32wd_to and this one did not leave any trace in > mtd2. Thanks, this is (very rare) internal bug 144730, which is marked as not anymore reproducible in latest internal release. In the internal issue it has been noticed only when doing very large number of (long) Skype calls. Was your use-case related to Skype usage?
(In reply to comment #108) > I tried running the device in r&d with no-lifeguard but that didn't help, I > still got watchdog reboots instead of lockups. Is that expectable or did I do > something wrong ? There are several watchdogs in the device. Which one you disabled?
(In reply to comment #99) > -----------------------------(In reply to comment #72) > > Added internal bug number for freeze&reboot sometimes happening (in some > > devices) when the device is woken up from idle (idle here meaning CPU idle > > state, not screen blank etc). > > On an assumption that some number of the 32wd_to HW watchdog reboots are due to > > power management, maybe somebody having them (especially when waking up the > > device) could try disabling the CPU voltage & frequency scaling and see whether > > that helps significantly? > > > this helps definitly, thank you! no reboot since i changed this! ~ 4 hours ago. > was doing the same stuff like befor, where my device reboots up to 10 times. > > i will check it until tomorow if it helps really, but for now it looks good! > > best regards & merci! > This didn't help for me. Still reboots all the time. Propably >50 in two days.
> Thanks, this is (very rare) internal bug 144730, which is marked as not anymore > reproducible in latest internal release. > In the internal issue it has been noticed only when doing very large number of > (long) Skype calls. Was your use-case related to Skype usage? No. Just regular web browsing. Good news it has been corrected. Can't wait for firmware update.
got my new n900 yesterday. The phone keeps rebooting on use. It didnt re-boot for the longest time while it was charging. Off the charger it re-boots every 5 minutes or so. between yesterday and now It has rebooted atleast 50 times. phone is pretty much not usable. I dont see any pattern , reboot happens while I use the phone - not any particular application
thanks for finally raising the priority. i'd send my device back otherwise and stick with symbian.
Got N900 yesterday from Nokia USA site, and having reboots ever since.Tried disabling WLAN, Bluetooth etc etc no effect. Going to re-flash the device (imagine that on just second day!) Boot reason is always 32wd_to wish I could help more
My n900 is also suffering reboots from start. Some of those do not associate with network traffic (one reboot while maximising xterm), but then I yesterday got quite reliable reboots by visiting http://www.yle.fi. However, this morning it loaded ok (yesterday battery was quite low, now just charged). I also tested by watching youtube videos when driving 80+ km/h (not watching for real, just streaming :-), and no problems at that time. The first reboot I got when uploading package lists i.e. no additional packages were installed. Also changing scaling_governor to userspace did not help. All traffic is via 3G network. Most reboots are 32ws_to, but there were some other too and dsme/stats/ lists Xorg, ohm-session-agent, sapwood-server and hildon-sv-notification-daemon.
N900 spontaneously rebooting regularly yesterday, today it doesn't even start. During power on I'll get the regular Nokia on white background then the animated 5 white dots starts. After about 10s the animation stops and always the 2nd from left dot is largest and it hangs at this point. Tried battery out/in, another T-Mob sim... still 5 white dots and nothing else.
(In reply to comment #118) > N900 spontaneously rebooting regularly yesterday, today it doesn't even start. > > During power on I'll get the regular Nokia on white background then the > animated 5 white dots starts. After about 10s the animation stops and always > the 2nd from left dot is largest and it hangs at this point. Tried battery > out/in, another T-Mob sim... still 5 white dots and nothing else. > please see top of the page: "Bug 6334 blocks:" and visit bug # 6350
I have received my N900 yesterday and I experience random reboots problem too, so far I've had easily over 10 reboots within about 3-4 hours of real use. My /proc/bootreason is pretty consistent in these cases and always points at 32wd_to. As noted in some previous comments, there is no specific pattern that could give us some clue. The very first reboot happened on virtually vanilla device, within literally 10 minutes after the very first device switch-on. Later reboots were totally random, sometimes when device was in constant use, sometimes when it was idle for a while, as I said - no regularity on this, whatsoever. I came across a suggestion that some speficic SIM cards might cause this problem, so I removed it now and will see how it goes. Anyhow, I *think* this might be a hardware-related issue, unfortunately. Friend of mine also recived N900 yesterday from the same supplier (MPD UK) and after heavy use for most of the day, he didn't experience a single reboot so far. So, my loose guessing is, some batch of devices might have a faulty memory and/or on-board chip or sth (or perhaps a wacky SIM card). If it was strictly software-related issue, then I guess *everyone* with 42-11 would experience similar thing, isn't it?
Crash reporter is giving me a number of reboot-32wd-to PID 0 died to signal 0. Seems suspicious!
(In reply to comment #120) > I came across a suggestion that some speficic SIM cards might cause > this problem, so I removed it now and will see how it goes. Just a quick follow-up: N900 just rebooted without a SIM card inside. Reason as usual: 32wd_to :( It happened when device was doing literally nothing apart from lying on the desk with charger plugged in. I have resumed it from sleep moments before reboot happened, tough, but I did that many times within last hour and reboot didn't occur. I'm starting to get into "warranty replacement" mood...
yes, reboots happen even in offline mode. from my experience i mainly suspect two reasons: - heavy load (using microb or midori seem to raise the probability of a reboot) - resuming from sleep the combination of both seem to have the highest probability of a reboot: - resumeing from sleep and using a browser instantly
32wd_to error. Seems completely random in time and app (maybe more frequent when automatically rotating to phone app, but hard to say for sure). It freezes for a sec or two, then reboots. Happends every other hour or so. Last night I had to take the battery out to make the keyboard lightcome on. Manually on-off didn't help (unrelated?)
(In reply to comment #121) > Crash reporter is giving me a number of reboot-32wd-to PID 0 died to signal 0. Crash reporter will check /proc/bootreason slightly after boot and if that is 32wd_to (i.e. HW watchdog reboot), it will store potentially relevant information (like mtd2 oops partition) to a "rich core" crash file, which it will then offer to be uploaded.
(In reply to comment #125) > (In reply to comment #121) > > Crash reporter is giving me a number of reboot-32wd-to PID 0 died to signal 0. > > Crash reporter will check /proc/bootreason slightly after boot and if that is > 32wd_to (i.e. HW watchdog reboot), it will store potentially relevant > information (like mtd2 oops partition) to a "rich core" crash file, which it > will then offer to be uploaded. > Aparently the way it's working for me is 1. I get the reboot-32wd crash notification 2. a few minutes later I get a reboot It might just be I'm in countercycle and it's reboot then crash notification but I'm not getting this notifications right after boot, it's during normal operation. I've uploaded a few crash reports to the site during this morning (WET) let me know if you need help locating them.
(In reply to comment #126) > Apparently the way it's working for me is > 1. I get the reboot-32wd crash notification > 2. a few minutes later I get a reboot I've never heard that Crash reporter could cause a reboot. > It might just be I'm in countercycle and it's reboot then crash notification > but I'm not getting this notifications right after boot, it's during normal > operation. Some of the main applications are pre-started after bootup. Crash reporter waits until that's done before it saves the wd32_to reboot information and proposes to upload it. > I've uploaded a few crash reports to the site during this morning (WET) let me > know if you need help locating them. If the crash reports are about reboots, we'll deal with them based on statistics (oops backtraces occurring more often get more attention, something happening only once i.e. completely non-reproducible and possibly caused by the more frequent oopses, will be ignored). If the crash reports are about applications or other processes, it would be nice if you could file a separate bug report where you describe (preferably re-producible) use-case needed to trigger the crash. (In reply to comment #117) > Most reboots are 32ws_to, but there were some other too and dsme/stats/ lists > Xorg, ohm-session-agent, sapwood-server and hildon-sv-notification-daemon. Could you install Crash reporter? Xorg and sapwood-server termination will cause device to be rebooted. If hildon-sv-notification-daemon terminates too many times (in a row) when it's restarted, that will also cause device to reboot (it plays the phone ring tone). In that case I think the dsme/stats row for that should have '*' in it. Rich core dumps for these processes don't include user's private information (unless you've installed also syslog).
where to get the crash reporter for download?
(In reply to comment #128) > where to get the crash reporter for download? The package is here: http://repository.maemo.org/pool/fremantle/free/c/crash-reporter/ I'm not sure which repository one needs to enable to install it. Andre?
@Eero (& other Nokia developers) - do you consider this case as possibly hardware-related? I mean is there a chance that some faulty piece of hardware inside device may cause 32wd_to reboots? Complete randomness of this case and the fact that *some* users experience frequent reboots, while others don't experience them at all, might suggest there could be a batch of faulty (hw-wise) units. How do you feel about this from core platform developer perspective - if you don't mind me asking?
Well, to be honest. My device reboots once per 2 days or so. So it's not *often* neither *not at all*. (I use it for watching one movie per day/browsing net for 30 min/ reading new mails). The reason is of course 3wd2_to. I've noticed only that it happens only on heavy load of CPU. - Adding a contact info, new fields (that was the most often at the first days, probably the best reproduction step in my case) - A call coming during watching a movie (crash during call) - Switching window fast
(In reply to comment #130) > Complete randomness of this case and the fact that *some* users experience > frequent reboots, while others don't experience them at all, might suggest > there could be a batch of faulty (hw-wise) units. That would be interesting, as I had maybe 2 reboots shortly after getting the device and since ~2 weeks no reboots happen. While I don't recall what I was doing when the first reboot occured, the second one followed shortly after switching off the offline mode after the whole night.
(In reply to comment #130) > @Eero (& other Nokia developers) - do you consider this case as possibly > hardware-related? I mean is there a chance that some faulty piece of hardware > inside device may cause 32wd_to reboots? none of the developers nor any nokia staff will admit a hardware problem, even if they would be aware of such a problem. otherwise people could take legal steps easily, just think of microsoft and the whole bunch of defective xbox 360. it took them about a year to tell the truth to their, err, important customers. let's hope nokia has tested the production devices exhaustively. i'm still waiting for my replacement device that should have arrived yesterday..
(In reply to comment #133) > i'm still waiting for my replacement device that should have arrived > yesterday.. which has arrived just now! i have two devices for some days now as well as to SIM cards from the same provider. please let me know if i can help out in any way.
(In reply to comment #133) > none of the developers nor any nokia staff will admit a hardware problem, even > if they would be aware of such a problem. otherwise people could take legal > steps easily, just think of microsoft and the whole bunch of defective xbox > 360. it took them about a year to tell the truth to their, err, important > customers. That sounds fair, so... sorry for asking. :( Just got another reboot. Device was lying on desk doing nothing for over 3 hrs, now I picked it up, launched phone app and started dialling a number (pressing digits). While doing that device freezed, followed by reboot after about 7-8 seconds. Reason: Nokia-N900-42-11:~# cat /proc/bootreason 32wd_to
(In reply to comment #130) > @Eero (& other Nokia developers) - do you consider this case as possibly > hardware-related? This bug contains many different reboot issues. One set of issues is system service crashes. These seems to be quite rare in this bug though. Another set is crashes when the device is heavily used. This could be memory management related issue (e.g. between CPU, GPU and DSP, they all can change the memory mappings). One set seems to be related to power management (device wakeup from sleep) and happening more often on some specific devices, but it may be more of a slight difference in how they behave than "hardware bug"[1]. Last set seems to be related to networking and an Oops in network related functionality. This may be something that triggers based on what kind of a network environment one has or traffic that network has. Most of them so far seem to be triggering randomly, but that doesn't mean that it would be a HW issue. Things that depend on power management, memory management, network environment, timings etc on the kernel side, may get triggered seemingly randomly when the device has as complex HW and SW interactions as what e.g. N900 has. The important thing is to check what kind of reboot is in the question; sw_rst or 32wd_to, whether former was because of a critical system service termination, or whether they were because of some specific kernel oops, or whether 32wd_to was just due to device freezing (without Oops being logged) and provide the information in which kind of situations these happen and steps leading to it. Based on that information from all of you, we can then try to come up with specific steps where some *specific* reboot cause can be nearly always be triggered within reasonable time (say 15 mins). After that finding the cause for the bug and fixing it becomes much easier. [1] As to HW, every device from every manufacturer has "HW bugs", at least if you consider any component in device working even slightly differently from its specification as a bug. SW adapting to these is normal driver work. Then there are variations between individual devices. HW in devices is not 100% identical, they just comply to certain set of tolerance limits and functionality tests. Some components are calibrated at the manufacturing line and these calibrations may also differ between devices. With the complex HW & SW combinations & interactions & radio/network environments these small variations may sometimes cause unexpected situations for the SW. As to whether one could say that some issue is a "bug" in some specific device HW, requires first determining the exact cause of the issue and whether SW can handle that reasonably.
(In reply to comment #129) > (In reply to comment #128) > > where to get the crash reporter for download? > > The package is here: > http://repository.maemo.org/pool/fremantle/free/c/crash-reporter/ > > I'm not sure which repository one needs to enable to install it. Andre? > It's on SDK tools, fremantle/tools
(In reply to comment #127) > (In reply to comment #126) > > Apparently the way it's working for me is > > 1. I get the reboot-32wd crash notification > > 2. a few minutes later I get a reboot > > I've never heard that Crash reporter could cause a reboot. > Sorry, that's not what I meant. I meant crash-reporter telling me some process died and then getting a reboot from that but that was me missunderstading the UI.
>> http://repository.maemo.org/pool/fremantle/free/c/crash-reporter/ > It's on SDK tools, fremantle/tools could you please explain how to get crash reporter installed on a vanilla device?
(In reply to comment #139) > >> http://repository.maemo.org/pool/fremantle/free/c/crash-reporter/ > > It's on SDK tools, fremantle/tools > > could you please explain how to get crash reporter installed on a vanilla > device? > Go to App manager, Application catalogues, New Web address: http://repository.maemo.org Distribution: fremantle/tools Components: free non-free Make sure Disabled is unticked. Crash reporter should show up on your apps list.
(In reply to comment #140) > > could you please explain how to get crash reporter installed on a vanilla > > device? > Make sure Disabled is unticked. Crash reporter should show up on your apps > list. thanks! just stumbled upon http://bec-systems.com/site/569/omap3-resume-timing - due to my lack of knowledge i'm unable to determine any relevance, so please have a look for yourself.
*** Bug 6767 has been marked as a duplicate of this bug. ***
Sadly I have been struggling with this too for the past four days. I have tried almost everything I can think of (including much of what I've read on this report). I've flashed the eMMC and the firmware to each of the three available, yet had no luck. 99% of my reboots correspond with 32wd_to. Sadly random does appear to be the only thing I can use to describe this. Online & Offline, Wifi, GPRS, Bluetooth... none of it appears to be correlated. Fresh install vs. loaded with apps, no difference. Please let me know if there is something that needs to be tested. I should have the device for about 5 more days before my replacement arrives.
Experiencing random reboots with my N900. No particular pattern to what I do when the reboot occurs. Sometimes happens when left idle; sometimes happens when actively using it. Device stops responding, then after a bit of time it switches to the five-dot boot screen and boots up again. Happy to provide any and all information needed to debug this. Information requested from comments 20 and 39: Software version: 1.2009.42-11.002 /proc/bootreason: always 32wd_to, each time I've checked. Happened both before and after I set up Wifi. Bluetooth not enabled. I'll attach mtd2 momentarily. Please let me know if I can provide any other information to help debug this problem.
Not bothering to attach mtd2 after all; it consists entirely of 0xFF: /tmp$ zcat mtd2.gz | hd 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00040000 So, no useful oops data. Please let me know if I can provide any other information.
Some additional information which might help: when everything freezes right before a reboot happens, the device stops responding in various ways, including vibrating in response to a screen tap, turning the keyboard light off when closing the device, playing audio (it starts stuttering the last instant of audio repeatedly until reboot). When a reboot *does* happen, the screen goes dark, switches to a Nokia logo with no backlight, then starts the five-white-dots progress indicator, and then starts back up.
(In reply to comment #146) > Some additional information which might help: when everything freezes right > before a reboot happens, the device stops responding in various ways, including > vibrating in response to a screen tap, turning the keyboard light off when > closing the device, playing audio (it starts stuttering the last instant of > audio repeatedly until reboot). > > When a reboot *does* happen, the screen goes dark, switches to a Nokia logo > with no backlight, then starts the five-white-dots progress indicator, and then > starts back up. > my symptoms were exactly the same.
Here's one more thing that the people suffering from frequent "wakeup from idle" 32wd_to reboots could try out: - increase the screen blank timeout to the maximum (2 minutes) in the control panel display applet - instead of letting the screen blank on its own, use the screen lock key on the right side to blank & unblank the screen Does that significantly reduce the frequency of reboots?
(In reply to comment #148) > Here's one more thing that the people suffering from frequent "wakeup from > idle" 32wd_to reboots could try out: > - increase the screen blank timeout to the maximum (2 minutes) > in the control panel display applet > - instead of letting the screen blank on its own, use the screen > lock key on the right side to blank & unblank the screen > > Does that significantly reduce the frequency of reboots? > I will go ahead and try to be extra-conscious of this going forward but I can say that I almost exclusively use the lock key and still get reboots quite frequently. I often get reboots when the machine should not be going into, or coming out of, idle mode; it often happens during direct use.
(In reply to comment #148) > Here's one more thing that the people suffering from frequent "wakeup from > idle" 32wd_to reboots could try out: > - increase the screen blank timeout to the maximum (2 minutes) > in the control panel display applet > - instead of letting the screen blank on its own, use the screen > lock key on the right side to blank & unblank the screen > > Does that significantly reduce the frequency of reboots? That actually could make some sense, as for example yesterday and today when I was on train from/to work for about an hour, I was using my N900 constantly, not letting to go sleep by itself (unintentionally), and it haven't rebooted at all. However, once I got back home and put device aside, just using it occasionally, it rebooted three times within about an hour. Changed my backlight timeout to 2 minutes now and will try to use slide lock all the time. Hopefully it will give us some clue. Fingers crossed!
Some additional analysis, trying to eliminate possible causes: I've had it reboot both while idle and not touching it, while bringing it out of idle, and while actively using it. No particular userspace application causes it; in fact, I've had it happen while at the desktop and not running anything. I've had it reboot while out and about, away from my home wifi network, and I haven't yet configured any other wifi networks, so I know it can happen while not associated to any AP. That doesn't rule out the possibility of an issue with wifi AP scanning or similar, of course. I've definitely had it reboot while actively interacting with it, but I do have the general (very possibly mistaken) impression that it seems to reboot more often when I ignore it than when I use it. Oh, and one more symptom of the reboot: (In reply to comment #146) > Some additional information which might help: when everything freezes right > before a reboot happens, the device stops responding in various ways, including > vibrating in response to a screen tap, turning the keyboard light off when > closing the device, playing audio (it starts stuttering the last instant of > audio repeatedly until reboot). If it hangs while vibrating, it keeps vibrating until it reboots.
(In reply to comment #151) > I've definitely had it reboot while actively interacting with it, but I do have > the general (very possibly mistaken) impression that it seems to reboot more > often when I ignore it than when I use it. Yes, I have quite similar impression, but it's still just an impression, not proven by any sort of firm evidence.
(In reply to comment #151) > I've had it reboot while out and about, away from my home wifi network, and I > haven't yet configured any other wifi networks, so I know it can happen while > not associated to any AP. That doesn't rule out the possibility of an issue > with wifi AP scanning or similar, of course. I've had it reboot multiple times in "offline" mode. No cell radio, no bluetooth, no wifi, no GPS... so I do not think that it is related to any connections.
Again repeating: There seem to be multiple reboot reasons. You need to check which kind of reboot you got before "assigning" it to a certain kind of device usage. On some rare[1] devices we're sometimes able to reproduce the power management related issue with idling & wakeups[2], so that's being taken care of, as is the rare Xorg issue from comment 3 (which should be already fixed internally). [1] E.g. the device I'm using daily, has never rebooted during last few weeks. [2] Note that these kind of PM issues are very hard & slow to debug. So far there's no easily reproducible use-case for them and they cannot be debugged properly with either SW or HW debuggers (deep sleep disables clocks even for HW lines used for HW debugging). So fix for this particular issue may take quite a bit of time. As to the other reboot issues... If somebody can find a reproducible test-case for any of these reboots (the crash happening reliably with some _specific_ use-case, not randomly, preferably within few tens of minutes), getting information on the environment where it triggers and detailed steps on how to reproduce them[2] would be greatly appreciated. For example for the WLAN related reboot we got some leads from the oops log, but there's no reproducible test-case with which we could verify that the potential fix actually fixes the issue. ("potential fixes" may cause other issues, they get integrated to public releases only when we can verify that they actually fix some existing problem) (In reply to comment #78) > Created an attachment (id=1666) [details] [details] > mtd2 aftert few reboots Thanks. This contains a large number of oopses. Several of them are: [27673.128997] Unable to handle kernel NULL pointer dereference at virtual addre ss 00000000 It may be a potential memory corruption in kernel, maybe related to SGX driver oops backtrace I commented earlier (which is internal bug 149006, with no use-case how to reproduce the crash). Couple of them are the invalid instruction thing reported also earlier (there's an internal bug 145646 on that, but it's not reproducible at all). Then there are few others which haven't been in earlier oopslogs. (In reply to comment #84) > for me it seems that web browser & email app makes the reboots go wild. so it > could be connected to network operations. Depending on the content you throw at them, they can be very memory hungry. I.e. it could be also related to swapping. (In reply to comment #87) > for me this bug seems only to appear when using battery power. whenever i am > charging my phone no reboots occur or at least uptime is much much longer than > when using the phone on battery. I don't think the phone goes to deepest sleep when it's charging. (In reply to comment #89) > i will take a little bit back on my previous post. i took the phone off the > charger for a little while and did not do anything with it. as soon as i got > back home i put it back to charger and as soon as i woke it up from idle it > rebooted. Could it be that it had charged itself fully by that time? (I.e. wasn't anymore charging itself) > so. it seems it does not matter wheather i'm charging or not. What the boot reason still 32wd_to? (There may be several reasons for reboots, some phone&environment specific.)
Eero, I know that a lot devices are being returned as defective for this. My device is going back to Dell (and then onto Nokia I presume). Would it be possible for you to perhaps pick one up flagged with this sort of issue? I wish I could send you mine directly but something tells me that Dell wouldn't like that very much. If you had the device in your hands I think it would help immensely. There are hundreds (if not thousands) of devices experiencing this.
(In reply to comment #154) > As to the other reboot issues... If somebody can find a reproducible test-case > for any of these reboots (the crash happening reliably with some _specific_ > use-case, not randomly, preferably within few tens of minutes), getting > information on the environment where it triggers and detailed steps on how to > reproduce them[2] would be greatly appreciated. from a customer perspective: it seems like the manufacturer did not test the devices sufficiently, otherwise these obviously widespread issues would not exists in a retail product. sounds to me like we have to pay for the device and assist in debugging a real showstopper. would you personally accept these issues for a 600 euro device?
(In reply to comment #156) > from a customer perspective: it seems like the manufacturer did not test the > devices sufficiently, otherwise these obviously widespread issues would not > exists in a retail product. sounds to me like we have to pay for the device and > assist in debugging a real showstopper. > > would you personally accept these issues for a 600 euro device? Tom I understand your frustration (I share it), however this does not in any way contribute to the attempts to fix this bug. Please restrict your activities here to constructive ones. Forums (talk.maemo.org) are a more-correct place for such discussions.
Today I was playing around with the xterm, putting up a few aliases for it and stuff like that. Then I happened to write in uptime. Then it struck me. 2 DAYS without reboots, which was about 2 days minus 5 minutes more than I usually get without them. I didn't have anything special going on at the moment, so I decided to try to "force" the device to reboot. After reading a few surefire reboot scenarios from this list, I fired up Chess and got beaten twice by the AI, but no reboot. Played some Marbles instead. Again nothing. Minimizing both games, I went for the greatest fiend of them all, and opened talk.maemo.org on the browser. After 10 minutes I got bored, as the device chugged along without any problems. Then I started to think back, if I had made any changes that could influence this. I couldn't come up with anything, so I decided to continue to push the device. I noticed that one of my contacts was missing a profile picture, so I fired up Google Contacts on my desktop and added a picture, and started waiting for it to sync up(using Google MfE for contacts and calendar). My laptop already catched on with the update, but nothing on the phone. I decided to go and do a manual sync through the MfE settings panel. The wizard popped up asking if I want to create new account. "No I don't want a new account, where's my old one?". Struggling to find the old account, I decided to check when it had last worked. I opened Google Calendar on my desktop and what does it tell me? Last update came through about 2 days ago... I seriously don't know if I'm onto something here or not, but just figured if someone else could try this out. Probably not, because people here are getting reboots without any connections on etc. But I want peace of mind with this matter. It's one thing to get reboots all the time, which is in some sick way calming to me, as you know it's coming. Now I can't get the damn thing to break again, and it's killing me to wait when it's gonna happen again :) Funny thing that I can't seem to get my MfE working again on the phone, so I can't test if it would start rebooting again with it. It just won't go through the setup wizard with the same settings as before.
(In reply to comment #157) > Please restrict your activities here to constructive ones. sorry for my flaming tamper. i have two devices from amazon on my desk, willing to help as i've mentioned in my previous replies. as the nokia engineer said, there is no reproducable case, therefore i'm going to accept that i won't be able to do anything constructive and just shut up for now.
(In reply to comment #156) > from a customer perspective: Tom hensel, completely uninteresting here as this is a technical bugtracker. Please go to a forum or contact Nokia directly and avoid such unneeded clutter in this report (which is already crowded enough).
(In reply to comment #160) > Tom hensel, completely uninteresting here as this is a technical bugtracker. > Please go to a forum or contact Nokia directly and avoid such unneeded clutter > in this report (which is already crowded enough). please, feel free to delete my comments!
(In reply to comment #155) > Eero, I know that a lot devices are being returned as defective for this. My > device is going back to Dell (and then onto Nokia I presume). Would it be > possible for you to perhaps pick one up flagged with this sort of issue? No, they go through Nokia channels dedicated for this. Also, I'm not in the (kernel) team which analyzes these issues more in detail and fixes them. (In reply to comment #156) > from a customer perspective: it seems like the manufacturer did not test the > devices sufficiently, The devices have constant & extensive testing for HW & SW, both automated and manual, both short term and long term. At the manufacturing line the tests naturally need to be short and automated due to high volumes (and are for HW). > otherwise these obviously widespread issues would not exists in a retail > product. Based on on how many devices this seems to be happening, it doesn't seem that widespread. But as the issue is extremely annoying, people are naturally very vocal about it and it gets high visibility. Different people subscribed to this bug may actually be suffering from different issues, not things that are common to all people subscribed here. > sounds to me like we have to pay for the device and assist in > debugging a real showstopper. Assisting is voluntary. > would you personally accept these issues for a 600 euro device? At the frequency at which some of the people have described reboots to happen i.e. several times per day? Of course not. Few times a week would be acceptable for me, if I know that there will eventually be a fix for it. But that kind of frequent reboot behavior listed here is not normal device behavior. For example the device I use daily (with light usage) hasn't had any reboots in weeks. If you get these 32wd_to reboots constantly and reflashing doesn't help, you could consider getting a replacement for it. (Although we can sometimes reproduce the wakeup & idle issue on some devices, debugging these kind of PM related, very hard to reproduce issues and testing the potential fixes is very slow work. It's still unknown whether a fix for that can be done, verified *and* tested long & well enough for the next update.)
(In reply to comment #162) your detailled reply is much appreciated. thank you!
I can think of two things I can do to help here: a) I can go to a Nokia service point and swap my unit for a working one. This helps if the Nokia people have reverse logistics to make the unit reach the developers. b) I can run an instrumented image that can spit out more info. Nokia guys, is either workable ?
(In reply to comment #164) > I can think of two things I can do to help here: > a) I can go to a Nokia service point and swap my unit for a working one. This > helps if the Nokia people have reverse logistics to make the unit reach the > developers. > > b) I can run an instrumented image that can spit out more info. I don't think b) to help with randomly appearing wd32_to reboots where there's no oops logged. But if you get reboots because of oopses (or system service crash), then more information would be appreciated.
Guys I got my phone yesterday and I had a lot of reboots... It eventually got bricked I reflashed the firmware... It seems that it's better now.. Been using it for 1-2 hours and it only rebooted once I really hope there is a fix for this because returning the device is very annoying for me.. I live in Canada and got it from a US store and Im leaving Canada for the holidays... its complicated and I have 1 week to return it
(In reply to comment #166) > Guys I got my phone yesterday and I had a lot of reboots... It eventually got > bricked > > I reflashed the firmware... It seems that it's better now.. Been using it for > 1-2 hours and it only rebooted once > > I really hope there is a fix for this because returning the device is very > annoying for me.. I live in Canada and got it from a US store and Im leaving > Canada for the holidays... its complicated and I have 1 week to return it > Lol I just got a reboot after posting this post... Im pretty sure it has something to do with power saving because it happens when I leave my phone idle for 3 secs to 1 mins.. I then press something on the screen.. It turns on and the phone freezes.. After 2 secs it reboots
Folks, nO NEED to post guesses and suspicions. This bug report already creates enough bugmail for everybody subscribed to it. PLEASE READ COMMENT 20 BEFORE ADDING COMMENTS and always provide that information. Otherwise we are all just guessing. Thanks.
(In reply to comment #167) > (In reply to comment #166) > > Guys I got my phone yesterday and I had a lot of reboots... It eventually got > > bricked > > > > I reflashed the firmware... It seems that it's better now.. Been using it for > > 1-2 hours and it only rebooted once > > > > I really hope there is a fix for this because returning the device is very > > annoying for me.. I live in Canada and got it from a US store and Im leaving > > Canada for the holidays... its complicated and I have 1 week to return it > > > > Lol I just got a reboot after posting this post... > Im pretty sure it has something to do with power saving because it happens when > I leave my phone idle for 3 secs to 1 mins.. I then press something on the > screen.. It turns on and the phone freezes.. After 2 secs it reboots > That exact same thing happens to me! I leave it alone, then come back to it, try to send a message or play a song and it reboots, sometimes it freezes up on a song and sounds like a scratched record, stays frozen on the same annoying sound and after 10 seconds reboot. Sometimes it starts running really really slow, then freezes up, looses graphic quality and reboots... And I cant have it replaced since I live in Costa Rica and I bought it in the US...
(In reply to comment #134) Hey Tom , How is it going with the replacement phone ? Any reboot issues for similar usage as previous one. I am also waiting for a replacement from Dell, wondering how much that is going to help.
I know I repeat myself, but PLEASE keep this report focused and use the forum at http://talk.maemo.org/showthread.php?p=392303 for non-technical parts of this. Developers simply will NOT follow this report if there's 30 new comments per day but only a few of them are helpful and provide actual information while the rest is just "me too" without providing any useful TECHNICAL information. Again, see comment 20.
Also having random reboots similar to comment #67 "device stops responding and after couple seconds screen goes black and the 5 balloons -animation comes up booting the device to homescreen without pin -request etc" /proc/bootreason has 32wd_to /var/lib/dsme/stats/lifeguard_restarts has /usr/bin/ohm-session-agent: 1 (will check /var/lib/dsme/stats/* next time it happens) It has happened while browsing the web , configuring the desktop, activating a network connection, sending sms. Will test more but it feels like it happens more often if battery is low and / or if I let the device go to sleep often. Will flash firmware and emmc to check if reboots become lest frequent
As I understand it, /var/lib/dsme/stats/ won't contain anything useful for a 32wd_to hardware watchdog reboot. The "lifeguard" bits only give you software watchdog info. In my case, I've only ever had 32wd_to reboots, and I have nothing under /var/lib/dsme/stats/ .
Just had my 3rd random reboot in a course of 6 days I have own the device. This time I checked boot reason and it was 32wd_to. I woke the device from sleep and disabled my MSN account, leaving skype my only IM service and then set availability to online and pressed save. Now I was expecting the select connection dialog appear (I was in offline mode), but the screen went blank the device rebooted itself with a reason 32wd_to.
Reflashed both files (the "vanilla"-thing and firmware). First reboot occured when going to phone app (rotating) and pushing on the screen. _to - bug again. Noticed another thing while flashing. Production versions are supposed to come with maps preloaded. Mine certainly was not. The very first time I used maps it started downloading exactly like it did after reflashing(the "vanilla"-file does not have maps preloaded). Could some of these "production" devices actually be re-flashed pre-production devices?? I have to wonder. Nokia must have several dozen, if not hundreds, of these faulty devices by now, since a couple of weeks at least. In my opinion it is unbelievable that they do not work this bug and fix it ASAP. The very least is to find out if this is HW or SW. There are abselutely no reason for "us" to report these bugs. If the N900 was a car, everyone would be called back and fixed. The N900 is nice, but the way Nokia is handling this is simply unbelievable.
Getting reboots too. Retail n900. /proc/bootreason is always "32wd_to" Happened under following conditions: Wi-Fi On, 3G On, SIM installed. Wi-Fi On, 3G Off, SIM installed. Wi-Fi On, 3G Off, SIM not installed. Wi-Fi Off, 3G Off, SIM installed. Unfortunately I didn't test with Wi-Fi and 3G off *and* SIM removed. They happened both at home (where I tested with all the above settings), and at work (where I tested with Wi-Fi Off, 3G Off, SIM installed). Bluetooth were always off. Happened with or without charger connected. No additional apps installed. First reboot happened right after unboxing, when I adjusted the time I had set up in the initial setup screens. Other reboots happened randomly in any app, including the Telephone app. Sometimes rebooted when browsing the installed apps. The occational reboot when opening terminal to check bootreason. Sometimes happened after only a few seconds, sometimes could take up to several minutes. It *didn't* reboot at any point when just left to idle on desktop screen with no apps running. E.g. left it on for around 6h overnight, with alarm enabled that activated on time, and verified with bootreason that last bootreason was normal power off. Never rebooted during wakeup or sleep.
I have a device using Elisa SIM in Finland. Device is normal retail version. SW is 2009.42-11 Previously I used to get re-boots every hour or every 30min, especially if updating contacts and syncing with Google Apps. After disabling Foreca weather widget and setting MfE for manual sync, the re-boots are reduced really a lot (perhaps once or twice a day). I just tried to get the device to re-boot. I always have Skype and Nokia Messaging open but then started to add more applications. I also had it connected to 3G and Wlan. I opened several browsers and played with them; worked ok. Opened emails - all ok. Started Bounce (game) - all ok. Started Marbles (game) - immediate re-boot! I've now played with Marbles 4 times and it has crashed the device twice. However, I still am not able to re-produce it. I need to check how to provide logs about the reboots in future.
(In reply to comment #177) > Previously I used to get re-boots every hour or every 30min, especially if > updating contacts and syncing with Google Apps. After disabling Foreca weather > widget and setting MfE for manual sync, the re-boots are reduced really a lot > (perhaps once or twice a day). Could be network related... > I just tried to get the device to re-boot. I always have Skype and Nokia > Messaging open but then started to add more applications. I also had it > connected to 3G and Wlan. I opened several browsers and played with them; > worked ok. Opened emails - all ok. Started Bounce (game) - all ok. Started > Marbles (game) - immediate re-boot! I've now played with Marbles 4 times > and it has crashed the device twice. However, I still am not able to > re-produce it. And this could be screen update related (SGX driver or X server). Did you check what was /proc/bootreason on each of these cases and whether you have any oopses logged? (To get more readable logged oops output, one could install sp-oops-extract from SDK tools repository and do "sp-oops-extract /dev/mtd2".)
Nokia guys, how do we disable the watchdog rebooter ? I rather debug a crashed/locked up machine than a rebooting machine.
My device suffers from random reboots as well. (It's retail unit delivered to me from MPD 2 days ago.) To prevent that i tried: a) Reset device to factory defaults settings b) Update via NSU to this same firmware 1.2009.42.11 c) Use of Flasher ver. 3.5_2.5.2.2 / flashing firmware OS & eMMC content d) take of memory card e) take of sim card f) Use device without internet connection with default repository and software installed. g) switch off GPS h) tried set back light dim time from 10 sec - 2 min Even after applying above steps device reboots randomly regardless of battery charge level, plug in to charger or not. Based on that I can think is device fault rather than firmware OS.
(In reply to comment #180) > My device suffers from random reboots as well. Please see comment 20.
(In reply to comment #179) > Nokia guys, how do we disable the watchdog rebooter ? With the flasher tool. > I rather debug a crashed/locked up machine than a rebooting machine. If you're suffering from the idle deep sleep / wakeup related reboot issue, it's not debuggable that way. After device freezes completely, there's nothing else one can do without HW debugging facilities than to reboot the device. And what makes it harder to debug is that: - You cannot have the device connected to serial or some other thing which prevents the device from going to deep sleep, and - When the device is in deep sleep, even HW debuggers don't work (clocks for debug lines don't run) Only if your reboot issue is sw_rst (due to system service crash or oops) or wd32_to caused by kernel oops (i.e. you find regularly new stuff on the oops partition), it's debuggable by "mere mortals". But those seem be in minority based on the comments in this bug.
Created an attachment (id=1735) [details] MTD2 after new reboots - flash playing during active Skype Yesterday I was using the phone and have not encountered any crash. Today I returned home, connected to the network, changed my IM status, and again started surfing the web. During watching flash video on BBC it rebooted again. I got into investigative mode - after reboot I decided to watch the same video not in the full screen. My reasoning was that rebooting might be somehow connected to fullscreen flash, and yesterday (when it did not reboot) I tended not to use flash in full screen. Unfortunately it rebooted again after few minutes during surfing the next page (without flash). Then I decided to disable my availability on Skype and GoogleTalk, as it was also something that was not active yesterday. So after finished reboot, I used menu to choose "Disconnected" and again went to the BBC. I finished reading news, watched some movies, and it hasn't rebooted. Then I went to the YouTube, watched movie - again no crash. In summary - I believe that in case of my device reboots are connected to hight usage of WiFi with energy savings (see my comment #76), CPU+GPU (flash either embedded or full-screen; the latter causes reboots more frequently), availability on Skype/GoogleTalk. In most cases boot reason is 32wd_to - only once I had sw_rst (unfortunately I do not remember what I was doing just before it). I attach mtd2 after two today's crashes. I am not sure whether this new mtd2 should make my old one obsolete - if so, please check it as such.
I should probably split this into two new reports and copy the useful comments to them. * One report for sw_rst * One report for 32wd_to Summarizing a bit (finally, I should have done this earlier): ********************************** For non-technical "me too" comments without further info, please go to http://talk.maemo.org/showthread.php?t=35055 instead. ********************************** Please EVERYBODY install crash-reporter from the SDK tools application catalogue. See http://wiki.maemo.org/Extras-testing#Tools_for_testers for a how-to. (from Comment #129 and 137) ********************************** Please ALWAYS provide the output of these commands in X Terminal: cat /proc/bootreason ********************************** If the reboot reason is "sw_rst": Please ALWAYS provide also the output from this command in X Terminal: cat /var/lib/dsme/stats/* If the reboots continue after the next release (to be available in this month), please continue to provide report crash-reporter reports (see above). Also, please list which 3rd party software you have installed, as it always might be the case that this is not triggered by official Nokia software. (from Comment #20) ********************************** If the reboot reason is "32wd_to": Could you become root (install "rootsh" package) and do this as root: gzip -c /dev/mtd2 > mtd2.gz And attach the mtd2.gz file here? (from Comment #39) Does that significantly reduce the frequency of reboots: - increase the screen blank timeout to the maximum (2 minutes) in the control panel display applet - instead of letting the screen blank on its own, use the screen lock key on the right side to blank & unblank the screen (from Comment #148) Also, we need to know when exactly they occur: - After device goes to sleep (screen blanks etc)? - When device wakes / is woken up from sleep? - When device is being used? -> If yes, do the reboots happen also in offline mode? (from Comment #20) **********************************
(In reply to comment #148) > Here's one more thing that the people suffering from frequent "wakeup from > idle" 32wd_to reboots could try out: > - increase the screen blank timeout to the maximum (2 minutes) > in the control panel display applet > - instead of letting the screen blank on its own, use the screen > lock key on the right side to blank & unblank the screen Just a quick question to clear this up: is unlocking device by opening keyboard logically (ie. from software point of view) the same or different as using slider on the side of device? Also, how about taking/making phone calls, as it also wakes device up from deep sleep, obviously. Does that matter? Following this suggestion I am striving to always use a slider to lock/unlock device, but sometimes I forget that and unlock by sliding keyboard and I was wondering whether that does make a logical difference.
> > Could you become root (install "rootsh" package) and do this as root: > gzip -c /dev/mtd2 > mtd2.gz > And attach the mtd2.gz file here? > (from Comment #39) > I haven't attached any mtd2 yet cause mine keeps being empty. I'm also tracking /proc/kmsg which doesn't show anything suspicious.
(In reply to comment #185) > (In reply to comment #148) > > Here's one more thing that the people suffering from frequent "wakeup from > > idle" 32wd_to reboots could try out: > > - increase the screen blank timeout to the maximum (2 minutes) > > in the control panel display applet > > - instead of letting the screen blank on its own, use the screen > > lock key on the right side to blank & unblank the screen > > Just a quick question to clear this up: is unlocking device by opening > keyboard logically (ie. from software point of view) the same or different > as using slider on the side of device? From the power management point of view they should be the same. From the UI point of view, no (keyboard can trigger screen rotation). At least tapping the screen to wake it up goes through different route in HW. > Also, how about taking/making phone calls, as it also wakes device up from > deep sleep, obviously. Does that matter? That's completely different, then the phone is woken up by the cellmo side. Is somebody having reboots right after phone wakes up to a phone call? > Following this suggestion I am striving to always use a slider to lock/unlock > device, but sometimes I forget that and unlock by sliding keyboard and I was > wondering whether that does make a logical difference. The main thing was decreasing the power management "ping pong" by increasing the screen blank timeout. Because screen takes so much power compared to other things, AFAIK certain extra power saving things are done only when screen blanks. The lock key thing came from a comment elsewhere where it was claimed that in addition to increasing timeout that helped also in reboot. If you do things always the same way to wakeup the device and this causes less reboots (during several day period and similar kind of device usage in same environment), or more of them, than mixing different ways of waking up the device, this will help in narrowing down the reboot use-case(s).
(In reply to comment #187) > The lock key thing came from a comment elsewhere where it was claimed that in > addition to increasing timeout that helped also in reboot. If you do things > always the same way to wakeup the device and this causes less reboots (during > several day period and similar kind of device usage in same environment), or > more of them, than mixing different ways of waking up the device, this will > help in narrowing down the reboot use-case(s). Thanks for clearing this up. Constantly using slider to (un)lock device doesn't solve the problem, device still reboots, but I have an impression it reduced slightly. However, I will observe it more over the weekend, and also try returning to old usage pattern (quick backlight timeout plus not using slider all the time) to see if there's much difference.
I also have lots of random crashes, unfortunately the mtd2 file turns up empty all the time. I can reliably cause the N900 to crash when I start up gPodder, play a podcast and then start Marbles and start to play. Usually after a few seconds the N900 will freeze and then reboot. This happens in online as well as offline mode (no SIM inserted). Doing the same on the preproduction N900 I got at the summit does not cause a crash. Both devices run with the current SW version (1.2009.42-11). Using the browser with memory intensive web pages also leads to crashes. I highly suspect a hardware problem, either RAM or with the swapping. I am returning the N900 on Monday. If there are any test I could run and core dumps or other data to collect, please let me know.
Flashed FW (1.2009.42-11) and eMMC today, went straight to Web - selected my 3G connections, went to the following sites - www.speednet.test - all was fine - talk.maeomo.org - this page left web browser running and opened marbles ... not responsive for 2-3 seconds reboot , no pin, reason : 32wd_to tried to duplicate it , but couldn't. On the second try I did get an error while in marbles "problem with Web application" (translation from Portuguese not actual error)
hey, i think maemo 5 team doesn't found these problems on their N900. so they are not trying to solve this problems or i think they are not reading our problems. otherwise they would did something with reboot problems. any one has any idea about they are doing something with these..??? or when they are planing to release new version of Maemo 5...?????
(In reply to comment #191) > hey, > i think maemo 5 team doesn't found these problems on their N900. Please do not post completely useless comments like this one, or your Bugzilla account might be disabled. Bugzilla is a technical bugtracker. Read comment 184 and go to a forum to post your wrong assumptions. Thanks.
> That's completely different, then the phone is woken up by the cellmo side. > > Is somebody having reboots right after phone wakes up to a phone call? I've had all types of crashes but phone seems solid.
I have a basic doubt about this bug(s). Does this happen on *all* units ? There's a lot of people reporting problems on this bug but this is a minute part of owners. Is Nokia seeing a lot of returns for N900 or this sleep bug only affects a small number of units ?
Was able to reproduce reboots fairly consistent yesterday. On the road using only telephone connection, opening mail application and reading/rfreshing mail (gmail) caused reboots within 2 min every time (tried 5-6 times). Stopping the car, seemed to stop the reboots as well (at least for the time I was not mooving). 32wd_to error all the time. The same seemed to happen when using maps, but I didn't try more than a couple of times.
I am not able to produce a reboot when charging from the usb cable. The device has been completely robust while using it in this manner. I have had it to where the screen doesn't want to switch after pressing an icon repetitively, but after several seconds it does switch, whew:). My reboots are always 32wd_to and happen dozens of times per day of course. Reboots happen mostly when switching tasks, say from browser to terminal, stopping top with ctl c, or pausing, etc. I noticed something Eero questioned about stability of the device while charging,(as opposed to on a charging cable, but fully charged). I know some have said they thought they had experienced reboots while on a charging cable. But how about actually in a charging state from usb? I am at 1:05 of uptime right now, off the cable she'd have rebooted after checking the uptime. I will see how it behaves after full charge on the usb cable later.
(In reply to comment #194) > I have a basic doubt about this bug(s). Does this happen on *all* units ? > There's a lot of people reporting problems on this bug but this is a minute > part of owners. > Is Nokia seeing a lot of returns for N900 or this sleep bug only affects a > small number of units ? Either this is quite common or I'm really unlucky, I already changed my N900 because of this and the new one has this same problem. Over 30 reboots in two days. I'm using crash reporter to upload reboot reasons to Nokia.
(In reply to comment #197) > (In reply to comment #194) > > I have a basic doubt about this bug(s). Does this happen on *all* units ? > > There's a lot of people reporting problems on this bug but this is a minute > > part of owners. > > Is Nokia seeing a lot of returns for N900 or this sleep bug only affects a > > small number of units ? > > Either this is quite common or I'm really unlucky, I already changed my N900 > because of this and the new one has this same problem. Over 30 reboots in two > days. I'm using crash reporter to upload reboot reasons to Nokia. > Hello everyone! I´m new to the bug forum so go easy on me :) I can start off with confirming another rebooting N900. I recently returned my pre-production sample N900 that Nokia Sweden gave me to try out and got the retail version instead. The pre-prod phone was stable as a rock so no problem with that phone. The reboots started with the retail phone (2009-12-09) * Straight out of the box, first reboot in less then 5 min.(70% charged battery) No beta or any other software installed, since I have been following this thread. * It rebooted more or less every-time I closed the keyboard. * Repeated tapping on the touch-screen often caused a reboot short after a 1 sec freeze. * Surfing the net (N900 default browser) casued frequent reboots, sometimes instantly sometimes 10-15min. No change what so ever if the phone was charging or not neither USB or in wall, still rebooted a lot. One thing that changed after a while was the fact that just seconds before the phone rebooted it opened the camera photo folder by it self even if I wasn`t touching the phone. Rebooted within 10 seconds after that. Not a single picture was taken at that point. Unfortunately I didn´t have the crash report program in the retail phone, so can´t supply any data from the phone. After 7 hours since I received the phone and unboxed it it died in my hand (charger plugged into the wall) to never wake up again. Stone dead retail phone. Trying to flash it didn´t do anything so the phone is now shipped back to be examined to see if there is a hardware issue with the phone. Will get a new one early this week though :D My Nokia contact been using his N900 (retail) and it works flawless and never shown the slightest symptom, so there must be some hardware related issues as well, both his and my phone came from the same batch. So in worst case scenario it´s a mix of broken hardware and software related problem.
Hi, device had instantly reboots, no SIM or microSD added. Got 2 new devices in order to analyze. Both new devices had no reboots within 6 hours of testing. All three models made in Korea, no big jumps in IMEI number, so I suppose same production charge. Only used WLAN, no software installed. Only difference: I charged the first(faulty) device before 1st boot, I used the other two devices without charging. (Don't suppose to be relevant.) All tests done with unplugged charger. So there is definitely a HW bug or spread in HW-specification which is not handled correctly by the OS. Greetings Lopiuh
I can confirm when charging from USB cable, no reboots. (could this be as simple as faulty battery??)
Confirming random reboots. On or off the charger seems to make no difference. I also get occasional reboots without even touching the device. I tried playing with the ambient light sensor (someone mentioned that they perceived this as a possible cause) but was unable to reproduce. I am unable to reproduce the reboots consistently, ie. it's really random. My device is made in Korea.
Tried a battery from a 5800. Same reboot-issue. Battery is not it.
(In reply to comment #201) > Confirming random reboots. Such postings are not helpful. In general: Please see comment 184 before posting.
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.
Created an attachment (id=1753) [details] content of /dev/mtd2 after my latest crash Here is my mtd2.gz - created after latest of many wd32_to crashes - did also upload content from crash-reporter after the crash. /Lasse
(In reply to comment #200) > I can confirm when charging from USB cable, no reboots. (could this be as > simple as faulty battery??) > We might just be onto something here! I can confirm this as well. My device is plugged into the USB port on my computer but not in PC Suite mode nor Mass Storage mode. I read the comment on this last night and plugged my phone in. uptime currently reports 16 hours and counting. I have never seen more than maybe four before so I am thinking that this is not just a coincidence. I have reduced the rate at which I use the phone (its stuck to my desk like this) but I still have been using it somewhat regularly (50 sms in the past day or so, a few phone calls, some web use...). I will continue to leave it plugged in.
(In reply to comment #206) > (In reply to comment #200) > > I can confirm when charging from USB cable, no reboots. (could this be as > > simple as faulty battery??) > > > We might just be onto something here! I can confirm this as well. My device is > plugged into the USB port on my computer but not in PC Suite mode nor Mass > Storage mode. I read the comment on this last night and plugged my phone in. > uptime currently reports 16 hours and counting. I have never seen more than > maybe four before so I am thinking that this is not just a coincidence. I have > reduced the rate at which I use the phone (its stuck to my desk like this) but > I still have been using it somewhat regularly (50 sms in the past day or so, a > few phone calls, some web use...). I will continue to leave it plugged in. > Just a quick update... 30 hours of uptime with heavy use today, all while plugged into USB. Clearly we might finally have a starting point for tracking down the root cause.
> Just a quick update... 30 hours of uptime with heavy use today, all while > plugged into USB. Clearly we might finally have a starting point for tracking > down the root cause. I experience the same - no crashes when charging over USB. But I do have crashes when charging with the wall-socket-charger from the package. So what does that tell us? /Lasse
(In reply to comment #208) > > Just a quick update... 30 hours of uptime with heavy use today, all while > > plugged into USB. Clearly we might finally have a starting point for tracking > > down the root cause. > I experience the same - no crashes when charging over USB. But I do have > crashes when charging with the wall-socket-charger from the package. > So what does that tell us? > /Lasse I assume that the Wall charger would not have data pins? Or at least no data would be transferred between the Wall charger and the device, but naturally I could be mistaken. The USB charger would/could make use of the USB data pins. Possible that some signals between a PC and the device are keeping the n900 alive?
(In reply to comment #148) > Here's one more thing that the people suffering from frequent "wakeup from > idle" 32wd_to reboots could try out: > - increase the screen blank timeout to the maximum (2 minutes) > in the control panel display applet > - instead of letting the screen blank on its own, use the screen > lock key on the right side to blank & unblank the screen > > Does that significantly reduce the frequency of reboots? OK, here's my update on this: On Friday-to-Saturday night I reflashed both OS and eMMC on my N900, so basically I've got it back to factory state. For whole Saturday I've been using locking slider constantly and backlight timeout was set to 2 minutes. Result: 6 reboots in about 18 hours timeframe of usage. Sunday morning I set backlight timeout back to 30 seconds and I didn't care about slider much. Real usage timeframe was around 12 hours and there was something around 7-9 reboots in total (I lost the count at some point, so not sure about exact number), however they were ocurring in slighly weird pattern, ie. for the first 3-4 hours there were just two reboots, but then within about 2-3 hours I've got about 4-5 reboots and then they got calm again. As usual, 32wd_to was always a bootreason, all were totally random, regardless of system load, number of running apps, any specific usage pattern etc. One of the reboots happened when device was plugged to wall charger.
(In reply to comment #210) i did not have a single reboot since i've started using a replacement device, worked flawlessly from the first second on. been using this device for more than three days now, including loads of applications from -devel and -testing, therefore i get the impression that this one is going to work rock solid. serial number of the device is lower than the device it replaces, battery serial number is higher, though. maybe my conclusion is not "technical enough", so i'm sorry in advance if mr. klapper gets angry again, but from an empirical point of view i strongly suggest to request replacement devices instead of trying to hunt down defective hardware in every detail in a non-reproducable way. just my 5 cents. best regards, tom
I just discovered, by trying to copy all data from internal memorycard via my macbook pro (n900 as mass storage), that severel files have IO errors. Maybe this is connected to the crashes as well? /Lasse
(In reply to comment #208) > I experience the same - no crashes when charging over USB. But I do have > crashes when charging with the wall-socket-charger from the package. > > So what does that tell us? According to the kernel devs, device can go to deepest sleep when it's plugged to the wall charger, but not when it's charged through USB. I.e. the problem you're suffering from seems related to transition to/from the deepest HW sleep state. I had earlier commented how to disable power management frequency changing which was commented on not seeming to have effect on the reboots. To disable device from going to off-mode (deepest sleep), you can set "enable_off_mode" to "0" (as root): - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" - To do this permanently, change the "enable_off_mode" setting in /etc/pmconfig file to "0" and reboot the device. As the battery will then last only few hours regardless of whether device is used or not, it's not a workaround for this bug. It's just a test for pinpointing which problem the people in this bug are having. I would appreciate if you can test whether doing that will get rid of the reboots. Because of the effect on use-times, its better to switch device off when you're not going to use it for longer while, or attach the device to a charger. If disabling off mode gets rid of the reboots, next test would testing setting off mode back to 1 and disabling just "voltage_off_while_idle" setting. That wouldn't have as bad effect on the device use-times.
(In reply to comment #213) > To disable device from going to off-mode (deepest sleep), you can set > "enable_off_mode" to "0" (as root): > - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" > - To do this permanently, change the "enable_off_mode" setting in > /etc/pmconfig file to "0" and reboot the device. Sounds interesting. I have just disabled off-mode, and will let you know what happens. > If disabling off mode gets rid of the reboots, next test would testing setting > off mode back to 1 and disabling just "voltage_off_while_idle" setting. That > wouldn't have as bad effect on the device use-times. If the above "succeeds" I will try this too. Best regards, Lasse
I don't think sleep states necessarily explain all the 32wd_to reboots, since some of those occur while actively using the device; however, they may explain some of them, and in theory they could corrupt some bit of state in such a way that the device then has a problem later on. So, in an effort to test that hypothesis: does any means exist to forcibly go into off-mode right away? That would help reproduce the bug more quickly if so.
i have bought nokia products for over 10 years. the n900 is my last and may be my FINAL time. i dont know who to this give to but im hoping you can send this to the right place. these are issues that should be dealt with or add, etc. 1. add video call function 2. allow the secondary camera to be used when wanted to. why is it there if we cant use it. 3. "Turning Controls" tend not to work for whatever reason.( it works in the beginning then it stays in landscape mode no matter what you do until you restore the factory settings) 4. Allow option ti use the phone in "Portrait mode" 5. The ability to use ringtones on the contacts and separate ringtones. 6. a playlist and equalizer for the music player. 7. from the call log, allow for other options like texting or whatever.(seems to only allow that option for contacts you dont know) 8. headset earpieces to use full control of the control panel on them.(it sounds weird but refer to other phone earpieces with control panels) 9. Create an extended battery.( i dont need to say more for this one) 10. to be able to use "WiFi mode" when on "offline mode" . (this should be very important) 11. the ability to to see and hear "GIFF" pictures and "Midi" files and other files that cant be seen currently. there might be many more but these seem to be the most bothersome to me at least.
> To disable device from going to off-mode (deepest sleep), you can set > "enable_off_mode" to "0" (as root): > - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" > - To do this permanently, change the "enable_off_mode" setting in > /etc/pmconfig file to "0" and reboot the device. Yes, this works, now at 13.5 hours uptime with 8 hrs wall charger time in included. Using device normally. Prior to this I would have experienced 20+ reboots in that time.
(In reply to comment #216) > i have bought nokia products for over 10 years. the n900 is my last and may be > my FINAL time. i dont know who to this give to but im hoping you can send this > to the right place. > > these are issues that should be dealt with or add, etc. [...snip list...] This bug report does *not* represent an appropriate forum to air general grievances about Nokia or the N900. It represents a particular bug about some people experiencing random reboots with their N900. If you have general complaints, take them to the talk.maemo.org forum; if you have specific bug reports, file them in bugzilla as new bug reports; if you have feature requests, file them in Brainstorm; and if you want to return your N900, call Nokia Support. Please post in this bug report *only* if the following three conditions hold: 1) Your N900 experiences random reboots. 2) You have checked /proc/bootreason after the reboot, and it says 32wd_to. 3) You have something to add besides "me too", such as having tested one of the workarounds posted in the bug, or having a specific procedure to reproduce reboots, or having a new proposed workaround that successfully prevents reboots on your device. If (1) and (2) hold but you don't have anything to add besides "me too", just vote for the bug and/or add yourself to the CC. Posting in this bug report for any other reason will only take up the time of developers and contributors, and make the bug get fixed that much slower.
(In reply to comment #217) > > To disable device from going to off-mode (deepest sleep), you can set > > "enable_off_mode" to "0" (as root): > > - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" > > - To do this permanently, change the "enable_off_mode" setting in > > /etc/pmconfig file to "0" and reboot the device. > > Yes, this works, now at 13.5 hours uptime with 8 hrs wall charger time in > included. Using device normally. Prior to this I would have experienced 20+ > reboots in that time. I have tried this as well, experiencing no reboots for a couple of hours while only using the wall-charger. Afterwards I turned enable_off_mode back on and experienced *no* reboots for another couple of hours. After turning the device on and off, I got a reboot within an hour. After boot I turned enable_off_mode off and on and now have an uptime of 11:32 with normal use (on the wall-charger during the night, one phone call, tethered laptop using DUN on the train). In summary, it looks like you can turn enable_off_mode off and on as a work-around.
> Yes, this works, now at 13.5 hours uptime with 8 hrs wall charger time in > included. Using device normally. Prior to this I would have experienced 20+ > reboots in that time. I can confirm this too... my n900 has been (nearly) rock stable for the last 14 hours. Had one wd32_to crash though - it might be unrelated as I had a _lot_ of running applications and where testing some software from Maemo Extras Testing. Haven't tried enabling off-mode again, and disabling voltage_off_while_idle. That is next step in a few hours. /Lasse
(In reply to comment #213) > - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" > - To do this permanently, change the "enable_off_mode" setting in > /etc/pmconfig file to "0" and reboot the device. > I can confirm this. My uptime is now 12 h. No reboots so far. It has been on charger for 5 h, and in use the rest of the time
(In reply to comment #213) > (In reply to comment #208) > > I experience the same - no crashes when charging over USB. But I do have > > crashes when charging with the wall-socket-charger from the package. > > > To disable device from going to off-mode (deepest sleep), you can set > "enable_off_mode" to "0" (as root): > - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" > - To do this permanently, change the "enable_off_mode" setting in > /etc/pmconfig file to "0" and reboot the device. After 17h of device uptime I can definitely tell it works. Yay! We are getting somewhere with this finally :) > If disabling off mode gets rid of the reboots, next test would testing setting > off mode back to 1 and disabling just "voltage_off_while_idle" setting. That > wouldn't have as bad effect on the device use-times. This is what I'm going to test today.
(In reply to comment #222) > > If disabling off mode gets rid of the reboots, next test would testing setting > > off mode back to 1 and disabling just "voltage_off_while_idle" setting. That > > wouldn't have as bad effect on the device use-times. > > This is what I'm going to test today. Just edited /etc/pmconfig to enable off-mode and disable voltage_off_while_idle. Then I rebooted the phone. Had the first wd32_to crash within 5 minutes.
(In reply to comment #223) > Just edited /etc/pmconfig to enable off-mode and disable > voltage_off_while_idle. Then I rebooted the phone. > > Had the first wd32_to crash within 5 minutes. Yes, I confirm that too. Just got reboot, after ~20 minutes uptime maybe. Setting enable_off_mode = 0 again.
(In reply to comment #213) > > If disabling off mode gets rid of the reboots, next test would testing setting > off mode back to 1 and disabling just "voltage_off_while_idle" setting. That > wouldn't have as bad effect on the device use-times. > When trying this, my device rebooted within a couple of minutes. With enable_off_mode to 0, the device is much smoother as well. In normal mode or with _voltage_ set to 0, the screen stutters, not much but very noticable.
(In reply to comment #215) > I don't think sleep states necessarily explain all the 32wd_to reboots, since > some of those occur while actively using the device; "Active usage" doesn't necessarily prevent device from going to off mode. You may have small pauses in your usage while the device can sleep. (as I'm not kernel dev, I'm not completely sure about which kind of sleep states are reached in which kind of situations though.) (In reply to comment #219) > (In reply to comment #217) >>> To disable device from going to off-mode (deepest sleep), you can set >>> "enable_off_mode" to "0" (as root): >>> - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" >>> - To do this permanently, change the "enable_off_mode" setting in >>> /etc/pmconfig file to "0" and reboot the device. ... > I have tried this as well, experiencing no reboots for a couple of hours while > only using the wall-charger. Afterwards I turned enable_off_mode back on and > experienced *no* reboots for another couple of hours. > > After turning the device on and off, I got a reboot within an hour. > > After boot I turned enable_off_mode off and on and now have an uptime > of 11:32 with normal use (on the wall-charger during the night, one phone > call, tethered laptop using DUN on the train). > > In summary, it looks like you can turn enable_off_mode off and on as a > work-around. I discussed about this with the PM/kernel dev. Doing this at run-time is not extensively tested & debugged. It might not enable the power saving off mode properly. -> unfortunately only reliable way to do it is using /etc/pmconfig and rebooting so that the change is done at boot time. (In reply to comment #220) > I can confirm this too... my n900 has been (nearly) rock stable for the last > 14 hours. Had one wd32_to crash though - it might be unrelated as I had > a _lot_ of running applications and where testing some software from Maemo > Extras Testing. Could you "apt-get install sp-oops-extract" from SDK tools repo and tell whether "sp-oops-extract /dev/mtd2" reports any oopses? (In reply to comment #225) >> If disabling off mode gets rid of the reboots, next test would testing >> setting off mode back to 1 and disabling just "voltage_off_while_idle" >> setting. That wouldn't have as bad effect on the device use-times. > > When trying this, my device rebooted within a couple of minutes. Thanks for testing! > With enable_off_mode to 0, the device is much smoother as well. In normal mode > or with _voltage_ set to 0, the screen stutters, not much but very noticable. Waking up from the deeper sleep states implies some latencies, the device uses some heuristics to decide when it's OK to go to sleep, but they may not be ideal for all the cases. In which kind of cases the screen stutters with off mode enabled? And when that happens, does "dmesg" (run in XTerm) output show anything "suspicious" looking? (That issue could be discussed in another bug though.)
Created an attachment (id=1767) [details] content of sp-oops-extract /dev/mtd2 (In reply to comment #226) > > I can confirm this too... my n900 has been (nearly) rock stable for the last > > 14 hours. Had one wd32_to crash though - it might be unrelated as I had > > a _lot_ of running applications and where testing some software from Maemo > > Extras Testing. > > Could you "apt-get install sp-oops-extract" from SDK tools repo and tell > whether "sp-oops-extract /dev/mtd2" reports any oopses? Now Im running with off-mode on, and the voltage-setting off, and have a lot of crashes again. So I don't have the oops-extract from the single crash with off-mode off. Don't know if you are interested in this oops-log, but here it is. Best regards, Lasse
(In reply to comment #227) > Created an attachment (id=1767) [details] [details] > content of sp-oops-extract /dev/mtd2 Thanks, this seems to be crash in the DSP bridge driver. [52952.821807] [<bf1acf74>] (MEM_FlushCache+0x0/0x68 [bridgedriver]) from [<bf1c2c44>] (PROC_GetResourceInfo+0x1d4/0x1f8 [bridgedriver]) I think it's NB#138638 which will be fixed in the next major update. Did the reboot happen when you were using camera? > (In reply to comment #226) > Now Im running with off-mode on, and the voltage-setting off, and have > a lot of crashes again. Did you do the changes to pmconfig file and reboot the device? Does it seem that the reboots are more likely closer to the bootup of the device and usually come in a bunch? (What if device is powered off after (32wd_to) reboot and then turned on again?)
(In reply to comment #228) > Thanks, this seems to be crash in the DSP bridge driver. > > [52952.821807] [<bf1acf74>] (MEM_FlushCache+0x0/0x68 [bridgedriver]) from > [<bf1c2c44>] (PROC_GetResourceInfo+0x1d4/0x1f8 [bridgedriver]) > > I think it's NB#138638 which will be fixed in the next major update. Did the > reboot happen when you were using camera? No. just booted the device, started xterm then launched app manager to add the SDK repos.. then crash while writing the repos entry. > Did you do the changes to pmconfig file and reboot the device? Yes. > Does it seem that the reboots are more likely closer to the bootup of the > device and usually come in a bunch? (What if device is powered off after > (32wd_to) reboot and then turned on again?) Hmm.. They are indeed random, but maybe close to bootup and in a bunch isn't far from the truth? I'm totally sure though. Best regards, Lasse
(In reply to comment #226) > > > With enable_off_mode to 0, the device is much smoother as well. In normal mode > > or with _voltage_ set to 0, the screen stutters, not much but very noticable. > > Waking up from the deeper sleep states implies some latencies, the device uses > some heuristics to decide when it's OK to go to sleep, but they may not be > ideal for all the cases. > > In which kind of cases the screen stutters with off mode enabled? > > And when that happens, does "dmesg" (run in XTerm) output show anything > "suspicious" looking? > > (That issue could be discussed in another bug though.) > It will not stutter anymore right now. dmesg shows a lot of things, but one line almost at the end say (after a manual fresh restart): "Driver 'sd' needs updating - please use bus_tpe methods"
When it stutters, it is on the home screen when panning between each home screen.
A general question on this - does the positive outcome of suggestion regarding "enable_off_mode" setting made by Eero yesterda get us any closer to potential software-based fix for this issue, or is that still unclear? The reason for asking is because I have now opportunity to replace my device, but that means I'd need to send it back to my retailer and wait God knows how long for replacement, while if there was a fix coming soon, I might wait a bit for that.
It is now very low on battery, and I try to make it reboot (lots of apps, on/off slider etc), but it simply will not reboot. Tried sporadically for 30-45 minutes now. Erlier it would reboot within 5-10 min at least.
I also turned on bluetooth and made it on and visible (never had it on before)
Very erratic. After a bricking yesterday, I reflashed at 7PM or so. After little use and a restore from my SD card, the device behaved until 2AM or so, after it failed to acknowledge I had plugged in the charger and ran the battery mostly down. Shortly before I was able to plug it in the device rebooted. 32wd_to. The device came back up and was stable (though totally unused) for 9h30m, until I arrived at work. Minor use resulted in a reboot within 5 minutes or so, followed by erratic, random reboots throughout the day when interacted with. Here's something: Reboots almost entirely seem to occur during user interaction, whether intentional or not, such as in my pocket with the screen unlocked. From the behavior shortly before a crash, it also seems like CPU usage skyrockets right before it dies as behavior such as sliding or transitions before a reboot gets real choppy. Currently it's stable and has been up for 30 minutes. I've also hit bug 6350 twice now (likely as a result of this.) Installed: Facebook Widget VncViewer OpenSSH (server and client) Ruby 1.8 Xchat rootsh Connections: Wifi at home, 2.5G at work. Rootfs: 68.5MB available 16GB MicroSDHC card installed. Stock firmware, reloaded using flasher-3.5 (thank you VMWare for being so freaking awesome)
Created an attachment (id=1771) [details] another oops-extract just had many hours of stability with enable_off_mode=0 voltage_off_while_idle=1 Then I browsed to: http://tomch.com/maemaps.html tried it out for some seconds, and then had a 32wd_to crash. (as mentioned with off-mode off). Oops extract attached. /Lasse
Just reflashed my N900 again due to bug 6350, and shortly after coming back up it rebooted again. 32wd_to as before. Now that I've seen that the problem still occurs, I'll try disabling off mode and see if that fixes it.
Workaround in place; will report back with success or failure. I also re-checked my mtd2, and found this oops. I don't know how long ago it came from. ][ 743.026550] Unable to handle kernel paging request at virtual address 01364d18 [ 743.026611] pgd = cc110000 [ 743.026611] [01364d18] *pgd=00000000 [ 743.026611] Internal error: Oops: 5 [#1] PREEMPT [ 743.026641] Modules linked in: pn_pep vfat fat sd_mod scsi_mod iphb rfcomm sco l2cap ext3 jbd omaplfb pvrsrvkm bridgedriver g_nokia uinput board_rx51_camera omap_previewer_hack omap34xxcam_mod isp_mod iovmm videobuf_dma_sg videobuf_core omap3_iommu iommu2 iommu dspbridge ssi_mcsaab_imp phonet cmt_speech smc91x mii wl12xx mmc_block omap_wdt omap_ssi mac80211 crc7 tsc2005 omap_hsmmc nokia_av mmc_core hci_h4p bluetooth fmtx_si4713 et8ek8 ad5820 lis302dl videodev v4l1_compat compat_ioctl32 smia_sensor adp1653 leds_lp5523 tsl2563 smiaregs v4l2_int_device rtc_twl4030 rtc_core leds_twl4030_vibra twl4030_wdt led_class [ 743.026885] CPU: 0 Not tainted (2.6.28-omap1 #1) [ 743.026916] PC is at kmem_cache_alloc+0x30/0x84 [ 743.026916] LR is at sk_prot_alloc+0x2c/0x120 [ 743.026947] pc : [<c00b3e54>] lr : [<c020c440>] psr: 200000d3 [ 743.026947] sp : cc10be88 ip : cc10beb0 fp : cc10beac [ 743.026977] r10: c03b0cfc r9 : cc10a000 r8 : c03b2d54 [ 743.026977] r7 : 000000d0 r6 : 00000190 r5 : 01364d18 r4 : a0000053 [ 743.027008] r3 : 00000000 r2 : 00000001 r1 : 000000d0 r0 : cf076c00 [ 743.027008] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user [ 743.027038] Control: 10c5387d Table: 8c110018 DAC: 00000015 [ 743.027038] Process dbus-daemon (pid: 886, stack limit = 0xcc10a2e0) [ 743.027069] Stack: (0xcc10be88 to 0xcc10c000) [ 743.027069] be80: 0000006d 00000800 0000028b c037fe38 000080d0 cf076c00 [ 743.027099] bea0: cc10becc cc10beb0 c020c440 c00b3e30 0000028b c037fe38 00000001 cedf1900 [ 743.027130] bec0: cc10beec cc10bed0 c020dc4c c020c420 0000028b 00000001 c03b0cfc cedf1900 [ 743.027191] bee0: cc10bf14 cc10bef0 c02701b0 c020dc34 cc10a000 00000001 c037fee8 cedf1900 [ 743.027221] bf00: 00000000 cc10a000 cc10bf24 cc10bf18 c0270314 c0270164 cc10bf4c cc10bf28 [ 743.027252] bf20: c0209b78 c02702ac 00000000 00000001 00000001 00000001 00000000 beb09fb0 [ 743.027282] bf40: cc10bf6c cc10bf50 c0209d08 c02099e8 cc10bf78 00000000 c00c6170 00000000 [ 743.027313] bf60: cc10bfa4 cc10bf70 c0209d70 c0209cc8 cc10bfa4 cc10bf80 c00c63ec cedf1c00 [ 743.027343] bf80: 00000001 2a10dea0 beb0a014 00000120 c002cac4 beb0a018 00000000 cc10bfa8 [ 743.027404] bfa0: c002c940 c0209d1c 00000001 2a10dea0 00000001 00000001 00000000 beb09fb0 [ 743.027435] bfc0: 00000001 2a10dea0 beb0a014 00000120 beb0a138 beb0a010 beb0a018 beb09fd4 [ 743.027465] bfe0: beb0a010 beb09fb0 2a02ab78 4014588c 00000050 00000001 805b8021 805b8421 [ 743.027496] Backtrace: [ 743.027526] [<c00b3e24>] (kmem_cache_alloc+0x0/0x84) from [<c020c440>] (sk_prot_alloc+0x2c/0x120) [ 743.027557] r7:cf076c00 r6:000080d0 r5:c037fe38 r4:0000028b [ 743.027587] [<c020c414>] (sk_prot_alloc+0x0/0x120) from [<c020dc4c>] (sk_alloc+0x24/0x50) [ 743.027618] r7:cedf1900 r6:00000001 r5:c037fe38 r4:0000028b [ 743.027618] [<c020dc28>] (sk_alloc+0x0/0x50) from [<c02701b0>] (unix_create1+0x58/0x148) [ 743.027679] r7:cedf1900 r6:c03b0cfc r5:00000001 r4:0000028b [ 743.027679] [<c0270158>] (unix_create1+0x0/0x148) from [<c0270314>] (unix_create+0x74/0x90) [ 743.027709] r9:cc10a000 r8:00000000 r7:cedf1900 r6:c037fee8 r5:00000001 [ 743.027740] r4:cc10a000 [ 743.027740] [<c02702a0>] (unix_create+0x0/0x90) from [<c0209b78>] (__sock_create+0x19c/0x29c) [ 743.027801] [<c02099dc>] (__sock_create+0x0/0x29c) from [<c0209d08>] (sock_create+0x4c/0x54) [ 743.027832] [<c0209cbc>] (sock_create+0x0/0x54) from [<c0209d70>] (sys_socketpair+0x60/0x1bc) [ 743.027862] r4:00000000 [ 743.027862] [<c0209d10>] (sys_socketpair+0x0/0x1bc) from [<c002c940>] (ret_fast_syscall+0x0/0x2c) [ 743.027893] Code: e5905080 e5906090 e3550000 1590308c (17953103) ][ 743.028656] mtdoops: Ready 1, 2 (no erase) [ 743.028686] Kernel panic - not syncing: Fatal exception
(In reply to comment #226) … > > In summary, it looks like you can turn enable_off_mode off and on as a > > work-around. > > I discussed about this with the PM/kernel dev. Doing this at run-time is not > extensively tested & debugged. It might not enable the power saving off mode > properly. > -> unfortunately only reliable way to do it is using /etc/pmconfig and > rebooting so that the change is done at boot time. It looks like I can confirm this now. I ran down the battery from 100% to around 10% in about 8 hours with my "work-around". With enable_off_mode turned on at boot time, I went from 100% to > 80% in about the same amount of time and similar usage, ie. it looks like enabling it after boot doesn't really turn it back on.
Created an attachment (id=1775) [details] crash after trying to connect to WIFI I had just 3 reboots after trying connect to our company WIFI. ~ $ cat /proc/bootreason sw_rst ~ $ cat /var/lib/dsme/stats/* /usr/bin/ohm-session-agent: 1 /usr/bin/hildon-status-menu: 2 /usr/bin/ohm-session-agent: 1 /usr/bin/hildon-status-menu: 1
(In reply to comment #232) > A general question on this - does the positive outcome of suggestion > regarding "enable_off_mode" setting made by Eero yesterday get us any > closer to potential software-based fix for this issue, or is that still > unclear? The first thing is for as many people as possible who encounter this bug to check whether their reboot issue goes away with enable_off_mode setting. Reboots can have many different reasons (see below), if many of the people on CC have a different issue, how I could answer the above question...? The reboot when returning from idle issue which can be identified with the off mode thing would seem to be most common now though (and would seem to happen more frequently on some of the devices than others). We have now a potential kernel workaround for that issue, but as we don't yet understand why the issue happens[1], why the workaround helps and how to reliably trigger the issue (on the devices where it's actually triggerable within day), it will require several weeks of internal testing before it can go to a public SW update. If it causes regressions, it may take longer. Unfortunately we don't have a way/process for letting externals to test our internal fix candinates, but you could contact Quim Gil and ask whether he could arrange something (at least for this particular fix). [1] Debugging this particular thing can be done only with an oscillator (or a HW emulator which would be hundreds/thousands of times slower than real HW) and as there isn't a reproducible test-case, work on it proceeds slowly. (In reply to comment #236) > tried it out for some seconds, and then had a 32wd_to crash. (as mentioned > with off-mode off). Oops extract attached. Kernel DSP driver issue (NB#145181): [52952.821807] [<bf1acf74>] (MEM_FlushCache+0x0/0x68 [bridgedriver]) from [<bf1c2c44>] (PROC_GetResourceInfo+0x1d4/0x1f8 [bridgedriver]) See comment 228. (In reply to comment #238) [ 743.027496] Backtrace: [ 743.027526] [<c00b3e24>] (kmem_cache_alloc+0x0/0x84) from [<c020c440>] Same as in comment 70. No known cases internally, no use-case.
(In reply to comment #240) > Created an attachment (id=1775) [details] [details] > crash after trying to connect to WIFI > > I had just 3 reboots after trying connect to our company WIFI. Thanks, all of them seem to be due to the same kernel Oops: [44944.519866] Backtrace: [44944.519866] [<c002fe58>] (__bug+0x0/0x2c) from [<bf0cba08>] (rate_control_get _rate+0xb8/0x150 [mac80211]) [44944.519989] [<bf0cb950>] (rate_control_get_rate+0x0/0x150 [mac80211]) from [< bf0d1acc>] (ieee80211_pr ... Which is unresolved NB#106780. There's also a similar bug in upstream kernel: http://bugzilla.kernel.org/show_bug.cgi?id=12490 It can be reproduced when connected to Linksys WRT54GL AP with OpenWrt firmware working as ad-hoc creator. Seems to happen only with ad-hoc and a bug in the router(?). According to upstream kernel and our internal bug, if a fixed rate is set using "iwconfig wlan0 rate 1M fixed" then this crash will not happen. I.e. your issue is different than the one here. Could you file a separate bug about it with the detailed information about the router you used and set the bug Alias field to "int-106780"?
(In reply to comment #241) > Kernel DSP driver issue (NB#145181): What is NB#145181 ? a bug in a closed nokia bugtracking system? /Lasse
(In reply to comment #241) > The first thing is for as many people as possible who encounter this bug to > check whether their reboot issue goes away with enable_off_mode setting. > Reboots can have many different reasons (see below), if many of the people on > CC have a different issue, how I could answer the above question...? > > The reboot when returning from idle issue which can be identified with the off > mode thing would seem to be most common now though (and would seem to happen > more frequently on some of the devices than others). > > We have now a potential kernel workaround for that issue, but as we don't yet > understand why the issue happens[1], why the workaround helps and how to > reliably trigger the issue (on the devices where it's actually triggerable > within day), it will require several weeks of internal testing before it can go > to a public SW update. If it causes regressions, it may take longer. Thank you for your response on that, that's understood. In that case I think I'll just proceed and replace the device since I have that opportunity now. Although setting enable_off_mode = 0 virtually fixes the problem for me (I didn't have even a *single* unexpected reboot since I applied that setting), you said yourself this is just workaround, not a fix as such. > Unfortunately we don't have a way/process for letting externals to test our > internal fix candinates, but you could contact Quim Gil and ask whether he > could arrange something (at least for this particular fix). OK, I will do that, thanks for suggesting.
Created an attachment (id=1778) [details] Latest mtd2 Included my mtd2.gz (It seems to me this is not updating after each reboot?) My unit is now fully charged, and it definitely reboots much more frequent than when the battery is almost empty.
(In reply to comment #243) > What is NB#145181 ? > > a bug in a closed nokia bugtracking system? Correct. The number should normally be in the related package changelog. It will also help if somebody gets a repeatable use-case for this so that a separate bug can be filed for it. (In reply to comment #244) > Although setting enable_off_mode = 0 virtually fixes the problem for me (I > didn't have even a *single* unexpected reboot since I applied that setting), > you said yourself this is just workaround, not a fix as such. It will ruin your device idle use-time, you cannot leave the device unused with screen blanked, but still running on your table for day(s) and expect it still to be powered up with some juice in the battery. For constant & active use, there's probably not that much difference in use-time. (In reply to comment #245) > Created an attachment (id=1778) [details] [details] > Latest mtd2 It had couple of SGX and maybe memory corruption related kernel oopses: ---- [28305.070129] Backtrace: [28305.070159] [<c00a6d24>] (remove_vm_area+0x0/0xac) from [<c00a745c>] (__vunma p+0x3c/0xd4) [28305.070190] r5:d15f6000 r4:00000000 [28305.070190] [<c00a7420>] (__vunmap+0x0/0xd4) from [<c00a7578>] (vfree+0x40/0x 48) [28305.070220] r7:d0ffc0e0 r6:cb759100 r5:00000400 r4:cd9d7870 [28305.070251] [<c00a7538>] (vfree+0x0/0x48) from [<bf1dac44>] (_VFreeWrapper+0x 10/0x14 [pvrsrvkm]) [28305.070343] [<bf1dac34>] (_VFreeWrapper+0x0/0x14 [pvrsrvkm]) from [<bf1daccc> ] (FreeVMallocLinuxMemArea+0x20/0x2c [pvrsrvkm]) -------- If you happen to get a somewhat reproducible test-case for it, a new bug focused on it (with crash keyword) would be appreciated. > Included my mtd2.gz (It seems to me this is not updating after each reboot?) It changes only when kernel oopses. You can check yourself what's in there with sp-oops-extract tool you can install from the SDK tools repository. Even "less /dev/mtd2" may show something readable. > My unit is now fully charged, and it definitely reboots much more frequent > than when the battery is almost empty. It would be nice to get a confirmation for this (and it not being related e.g. how much time there's from last (re-)boot).
the bug seems very easy to recreate using pdf reader. 95% of the time i'm reading something in pdf reader it will crash on me. 32wd_to. i think its because the device is trying to sleep but pdf reader won't let it for some reason.
(In reply to comment #247) > the bug seems very easy to recreate using pdf reader. 95% of the time i'm > reading something in pdf reader it will crash on me. 32wd_to. i think its > because the device is trying to sleep but pdf reader won't let it for some > reason. Most or all of these are 32wd_to reboots and you don't have oopses logged to /dev/mtd2? Do you have any other applications running at the same time? What extra home or statusmenu applets you have installed? Can you give a pointer to a document with which you can trigger this so that others can try it too? Thanks!
(In reply to comment #246) > > My unit is now fully charged, and it definitely reboots much more frequent > > than when the battery is almost empty. > > It would be nice to get a confirmation for this (and it not being related e.g. > how much time there's from last (re-)boot). I definately got the impression that it reboots more often when the battery is full. Unfortunately, I handed my device in as a DOA this morning and can't do any objective testing. Unless my replacement — due to arrive tomorrow — exhibits the same problem…
I can definitely confirm that changing enable_off_mode to 0 (via /etc/pmconfig and a restart) makes the most common cause of the random reboots go away. Without that workaround, I continued to see reboots minutes apart. With that workaround, I've seen only one reboot in a 24-hour period. (No new oops for the one I *did* see, though, unfortunately. It occurred while playing music, though I have no particular reason to believe that relates to the problem in any way. Also, while not connected to any wifi network.) Two other questions: (In reply to comment #241) > We have now a potential kernel workaround for that issue, but as we don't yet > understand why the issue happens[1], why the workaround helps and how to > reliably trigger the issue (on the devices where it's actually triggerable > within day), it will require several weeks of internal testing before it can go > to a public SW update. If it causes regressions, it may take longer. So, presumably the potential kernel workaround you have doesn't have the drawbacks of disabling off-mode, if you feel willing to potentially ship it after further testing; even if you can't post the actual public software update, can you say what kernel change seems to work around the problem? That *might* spark an idea on how to reproduce the problem. (In reply to comment #241) > The reboot when returning from idle issue which can be identified with the off > mode thing would seem to be most common now though (and would seem to happen > more frequently on some of the devices than others).
A few questions. Exactly how do I obtain this sp-oops-extract tool with my N900? Are these 32wd_to issues something that is likely to be fixed completely? Will this fix render my N900 to be of equal usability regarding battery life etc as any other N900? The reason for asking is that I can send mine in now, and get it replaced, but judging by correspondence with the store, this will take ages. The "enable_off_mode" is a better choice if this is just a matter of waiting.
Just had a second reboot since having disabled off-mode. Also while playing music; on the other hand, I'd *just* run ssh via the X terminal, and the N900 hung while SSH tried to connect. Again no new oops in mtd2. Still the same one from comment #238. Device still seems far more stable than without disabling off-mode.
(In reply to comment #250) > I can definitely confirm that changing enable_off_mode to 0 (via /etc/pmconfig > and a restart) makes the most common cause of the random reboots go away. > Without that workaround, I continued to see reboots minutes apart. With that > workaround, I've seen only one reboot in a 24-hour period. I've been having enable_off_mode=1 ever since I got the device, only 1 random reboot so far. So I'm not exactly sure how changing that would help. Must be some other configurations/applications you have on your device that's causing the rebooting minutes apart.
And just out of interest: 1. Does reflash fix the continuous random rebooting issue? 2. Which firmware variant are you using? I'm using the RX-51_0593611_1.2009.42.11.203.2_PR_F5_203_ARM.bin aka UK variant firmware.
Read all it! Sorry for bothering you (I haven't random crashes, only an video player application sw_rst). But I noticed that REBOOT differs from COLD BOOT (power OFF-ON) in N900, see my bug 7017). In my N900 the reboot turns graphic processor (SGX) and it's memory to definitely unstable state and it is cured by switching N900 OFF and then ON. I wandering - would it help if people with random reboot tries to do power OFF-ON cycle after random reboot... I don't try to work with unstable SGX.
I received my N900 today (I'm in Australia, but ordered it from a retailer in Hong Kong), and am unfortunately experiencing this bug. I have had maybe half a dozen reboots today. The two I had after reading this bug were both of the 32wd_to kind. Of the ones I can remember: - one occurred when waking the N900 (can't remember if it was with the slider or keyboard, sorry). - three occurred partway through entering a WEP key for an 802.11g network using WDS. The access points are one Billion BiPAC 7402VGP, firmware version 5.54b, and one Billion BIPAC-7500G, firmware version 5.52g. - at least two occurred while using Ovi Maps - one occurred while cropping a photo. I also had a browser open and pointing to a flikr page. I don't yet have a 3G SIM, so am connected to GSM, but don't have GSM IP connectivity. (My mobile provider offers it, and the N900 shows it, but it isn't enabled by my phone company for my account.) My mtd2.gz file does not contain any oopses (the file is all 0xFF). My firmware version is 1.2009.42-11.003. I hope to try disabling off-mode on the weekend and see if that helps.
Hello I'm living in Austria and I have the cold reboot problem as well. I'm a linux novice, so how do i set "enable_off_mode" to "0"? It asks for a password... Thanks
(In reply to comment #257) > Hello > I'm living in Austria and I have the cold reboot problem as well. > I'm a linux novice, so how do i set "enable_off_mode" to "0"? It asks for a > password... > Thanks In short: Install rootsh. See comment 184. Thanks for being willing to help, but please take basic questions to talk.maemo.org to avoid noise here in the bug report. Thanks! :)
(In reply to comment #251) > A few questions. Exactly how do I obtain this sp-oops-extract tool with my > N900? From the SDK tools repository: http://wiki.maemo.org/Documentation/devtools/maemo5#Installation > Are these 32wd_to issues something that is likely to be fixed completely? We're hoping so, for the particular issue discussed here. Let's see after testing the current fix candinate completes. There may still be other reasons for 32wd_to reboots which are much more rare (may e.g. happen in all devices, but only in some specific environment which Nokia doesn't have). Those should be filed as separate bugs. > Will this fix render my N900 to be of equal usability regarding battery life > etc as any other N900? As far as I've understood, yes. (In reply to comment #253) > I've been having enable_off_mode=1 ever since I got the device, only 1 random > reboot so far. So I'm not exactly sure how changing that would help. Then you don't have the issue discussed here. (In reply to comment #255) > I wandering - would it help if people with random reboot tries to do power > OFF-ON cycle after random reboot... NOTE: This is good thing to do also for the reason explained in bug 6350! If there's a difference between reboot frequency based on whether device did warm boot or one did cold boot after getting such a reboot, I'd like to hear about that.
I also face this issue. I checked the reboot reason once, and it was the same anyone get. It occurs at any time, whatever i'm doing. I believe -but was unable to confirm, that the phone slows before rebooting, and reboots if i insist. I have tried to launch lots of apps, switching many times very fast, and it did nothin. By the time i had my battery charged more than a half. It slept, then reboot few minutes later, without doing anything. I had closed all my apps juste before the phone got into sleep mode. My guess is (and i'm no expert): ram or swap don't flush correctly, causing the system to crash attempting to clear it.
Same happens here. Out of the box two days ago. Have not installed any 'extra' applications -- just using the preinstalled ones. Crashes very frequently -- and I mean every 10 minutes. Happens even when just scrolling thorough the desktop screens, arranging and adding shortcuts, web browsing etc.
(In reply to comment #261) > Same happens here. Out of the box two days ago. Have not installed any 'extra' > applications -- just using the preinstalled ones. > > Crashes very frequently -- and I mean every 10 minutes. Happens even when just > scrolling thorough the desktop screens, arranging and adding shortcuts, web > browsing etc. > What firmware variant (region) are you using?
(In reply to comment #262) > (In reply to comment #261) > What firmware variant (region) are you using? > 1.2009.42-11 -- Bought the device in Sonera shop in Finland and using couple of years old Sonera SIM.
i have the same firmware version, and it reboot when i checked it. My SIM is almost 10 years old, if it helps
Try reflash with UK firmware. I have no such continuous rebooting issues so far.
I set enable_off_mode to zero yesterday morning, and my N900 has been much more stable since then. I did have one 32wd_to reboot while listening to music over Bluetooth, and trying to use my Bluetooth headset to pause the music. This didn't feel at all like the previous reboots I was having, but I haven't yet had time to try and reproduce that---I just stopped using Bluetooth instead. My guess is that my reboot today was Bluetooth specific (perhaps related to bug 6766?). Apart from this one reboot, I have not had any other random reboots since disabling "off" mode. And I have spent more time using the device than I did during the first two days I owned it (during which time I had 10+ random reboots).
(In reply to comment #213) > (In reply to comment #208) > > I experience the same - no crashes when charging over USB. But I do have > > crashes when charging with the wall-socket-charger from the package. > > > > So what does that tell us? > > According to the kernel devs, device can go to deepest sleep when it's plugged > to the wall charger, but not when it's charged through USB. I.e. the problem > you're suffering from seems related to transition to/from the deepest HW sleep > state. > > I had earlier commented how to disable power management frequency changing > which was commented on not seeming to have effect on the reboots. > > To disable device from going to off-mode (deepest sleep), you can set > "enable_off_mode" to "0" (as root): > - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" > - To do this permanently, change the "enable_off_mode" setting in > /etc/pmconfig file to "0" and reboot the device. > > As the battery will then last only few hours regardless of whether device is > used or not, it's not a workaround for this bug. It's just a test for > pinpointing which problem the people in this bug are having. > > I would appreciate if you can test whether doing that will get rid of the > reboots. Because of the effect on use-times, its better to switch device off > when you're not going to use it for longer while, or attach the device to a > charger. > > If disabling off mode gets rid of the reboots, next test would testing setting > off mode back to 1 and disabling just "voltage_off_while_idle" setting. That > wouldn't have as bad effect on the device use-times. > Turning that enable_off_mode -> 0 did make my N900 usable. Before that it reboots every 10 minutes from the first powering on.
(In reply to comment #267) > (In reply to comment #213) > > (In reply to comment #208) > > > I experience the same - no crashes when charging over USB. But I do have > > > crashes when charging with the wall-socket-charger from the package. > > > > > > So what does that tell us? > > > > According to the kernel devs, device can go to deepest sleep when it's plugged > > to the wall charger, but not when it's charged through USB. I.e. the problem > > you're suffering from seems related to transition to/from the deepest HW sleep > > state. > > > > I had earlier commented how to disable power management frequency changing > > which was commented on not seeming to have effect on the reboots. > > > > To disable device from going to off-mode (deepest sleep), you can set > > "enable_off_mode" to "0" (as root): > > - To do this temporarily, do "echo 0 > /sys/power/enable_off_mode" > > - To do this permanently, change the "enable_off_mode" setting in > > /etc/pmconfig file to "0" and reboot the device. > > > > As the battery will then last only few hours regardless of whether device is > > used or not, it's not a workaround for this bug. It's just a test for > > pinpointing which problem the people in this bug are having. > > > > I would appreciate if you can test whether doing that will get rid of the > > reboots. Because of the effect on use-times, its better to switch device off > > when you're not going to use it for longer while, or attach the device to a > > charger. > > > > If disabling off mode gets rid of the reboots, next test would testing setting > > off mode back to 1 and disabling just "voltage_off_while_idle" setting. That > > wouldn't have as bad effect on the device use-times. > > > > Turning that enable_off_mode -> 0 did make my N900 usable. Before that it > reboots every 10 minutes from the first powering on. > Worked for me too, which is great, since while trying to disable enable_off_mode the phone rebooted twice (once while editing the file, second time when I was just going to reboot).
I can also confirm that setting "enable_off_mode" to "0" made my device rock solid - no random reboots at all after >1 hour intensive use (messaging, reading pdf, browsing, listening music, using camera, ...).
I did the same, but temporaly: echo 0 > /sys/power/enable_off_mode no probs at all, managed to configure my mail account, send message, i even played a bit without any problem. Seems to work, but i'll do further pushing tests^^
(In reply to comment #259) > (In reply to comment #251) > > Are these 32wd_to issues something that is likely to be fixed completely? > > We're hoping so, for the particular issue discussed here. > Let's see after testing the current fix candinate completes. Is this a real hardware issue (aka hardware broken) that affects only certain devices and could be worked around by software? I also have such a rebooting device and I'm about to return it to the vendor as it's unusable and I'm REALLY pissed and very disappointed by Nokia now :/ So, to make it short: I might think about keeping it if it's NOT damaged/broken and may become usable by a firmware upgrade. I'm NOT willing to having spent 600 EUR for a device that has hardware flaws/damages even IF it's worked around in software, so please explain and be specific. Thanks :)
Have the same trouble and ask the same questions : my N900 reboot when he is on battery or on charge but not with USB. Hope that will be fix soon :(
(In reply to comment #266) > I set enable_off_mode to zero yesterday morning, and my N900 has been much more > stable since then. > > I did have one 32wd_to reboot while listening to music over Bluetooth, and > trying to use my Bluetooth headset to pause the music. This didn't feel at all > like the previous reboots I was having, but I haven't yet had time to try and > reproduce that---I just stopped using Bluetooth instead. My guess is that my > reboot today was Bluetooth specific (perhaps related to bug 6766?). > > Apart from this one reboot, I have not had any other random reboots since > disabling "off" mode. And I have spent more time using the device than I did > during the first two days I owned it (during which time I had 10+ random > reboots). Hmm, I have since had two more 32wd_to reboots. One was when entering numbers using the Free42 calculator. The other was when pressing the "Call" button on the phone keypad when trying to make a SIP call. So although setting enable_off_mode to zero certainly makes this phone more stable, it doesn't completely fix the random reboot issue. :(
(In reply to comment #273) I g9t my n900 two weeks ago. now i have try to get replacement phone ten days, but vendor has refuse. > (In reply to comment #266) > > I set enable_off_mode to zero yesterday morning, and my N900 has been much more > > stable since then. I confirm this.I have test this a couple of days and zero makes phone almost rock and solid. There is still one or perhaps two wd32_to reboots per day. I noticed when enable_off_mode is zero mem usage is lower than normal. Can any one confirm this? In my phone top-command has never ever shows over 100 000K buff size. Is it normal?
Someone made a post somewhere stating UK version was not suffering any reboot: might be the case, but on his phone only i guess. I flashed several times my phone: -installed global version, crashed with 32wd_to -flashed eMMC, still crashes -installed UK version: still crashes with pwr_key as first reason, 32wd_to as second reason, then i decided to try USA version. If not working, my guess is i'll send back my phone tomorrow morning. As for me, the enable_power_off fix is the best, but battery goes down dramatically, and i don't feel like it's acceptable anyway.
Flashing with a USA version doesn't work, mismatch length for FIASCO subimage. I forgot to note: UK version allowed me to play mahjong without any probs (15min), playing chess crashed me the first time in less than 10 seconds -and it was not the first time i tried this to trigger the bug. I also should mention that rebooting while playing chess wasn't due to my finger pressing the power button, when the terminal said it was.
For your information: Nokia is currently testing a patch internally that makes this bug happen less often, but there are still a few devices showing this behaviour - hence there are several reasons. (And no real need to comment this I guess.)
(In reply to comment #273) > > I set enable_off_mode to zero yesterday morning, and my N900 has been much more stable since then. > Hmm, I have since had two more 32wd_to reboots. One was when entering numbers > using the Free42 calculator. The other was when pressing the "Call" button on > the phone keypad when trying to make a SIP call. So although setting > enable_off_mode to zero certainly makes this phone more stable, it doesn't > completely fix the random reboot issue. :( I have also been experiencing the random reboot issue. After applying the (non-permanent) fix it was indeed much more stable, however it still rebooted 1 or 2 seconds after accepting an incoming Skype call (same bootreason: 32wd_to). Have not attempted to reproduce yet, but would appreciate it if this would be included in the testing of the FW fix. Thanks.
(In reply to comment #278) > I have also been experiencing the random reboot issue. After applying the > (non-permanent) fix it was indeed much more stable, however it still rebooted 1 > or 2 seconds after accepting an incoming Skype call (same bootreason: 32wd_to). This is not enough to verify that the reboot is the same as what's discussed here (to which disabling off mode helps). You also need to check that the 32wd_to reboot in this case wasn't caused by an unrelated kernel oops. You can see the oopses from /dev/mtd2 (sp-oops-extract utility from the SDK tools repository shows the contents of this oops partition in more human readable form).
I bought my n900(made in Korea)in France last Friday 14 Dec. and experienced 30+ times' reboots. almost 4-10 times per hour. it happens when --email --website --xterminal --radio --photo taking etc... Checked the /proc/bootreason: 32wd_to every time. Change enable_off_mode to 0 in /etc/pmconfig then reboot the device: stable(8 hours heavy use without reboot). change enable_off_mode back to 1, and set voltage_off_while_idle to 0 then reboot : worse as usual, 3 reboots in one hour.
I left it charging overnight doing nothing else. In the morning was bricked (too many reboots). No way to bring it alive again... that is, until I bought a new battery. I unbricked it (too many unclean reboots bug) with the flasher (the method without flashing). 1) Could we be dealing with a defective bunch of batteries (no everybody experiences this problem) + bad power management? 2) Why a totally empty battery would not charge (no light turns on)? 3) Why would the device not work without a battery when plugged into the wall? 4) Why is this ticket unassigned but it's been said there is already a beta patch? 5) Is this patch a hardware-defect workaround or a software-bug fix? I am returning my N900 until further notice, it is unusable at this stage. Sorry I will not be able to provide more feedback after the 24th.
Brand new n900, just arrived yesterday, vanilla software. Started reboot itself like once every 20 minutes. Reboot happens with or without wifi on, doesn't seem to have anything to do with battery, and bootreason said 32wd_to. Once it even happened when I was not doing anything with it (in X-Terminal, but not typing or running anything).
Also got my brand new Nokia N900 yesterday, started rebooting within 5mins of use. Hardware revision 2101 UK version. Tried Global and UK images, but unable to flash eMMC XP, win 7 or Linux (opensuse 11.2). Have used different batteries, they work fine in Nokia 5800. Used the workaround mentioned above, still reboots I think. Will update if I have any more info. Sometimes removing the battery cover seems to make it more stable.
(In reply to comment #282) > Brand new n900, just arrived yesterday, vanilla software. Started reboot itself > like once every 20 minutes. Reboot happens with or without wifi on, doesn't > seem to have anything to do with battery, and bootreason said 32wd_to. Once it > even happened when I was not doing anything with it (in X-Terminal, but not > typing or running anything). Another day's use seemed to confirm that: 1. all reboots had something to do with touchscreen - if I stayed in x-terminal running irssi for hours, i.e. only keyboard typing and no touchscreen use, it never rebooted once. 2. all reboots so far happened when I was touching the touchscreen. If I was careful with the touchscreen, e.g. one touch at a time and wait for a bit between touches, reboots appeared very rarely. If I was touching fast on the screen, reboots became much more frequently.
I have recently received a warranty replacement unit which thankfully doesn't suffer from this issue any more, but I made other observation which might or might not be connected with random reboots. With the old N900, I mean the one that rebooted, FM Radio application from Extras-Testing didn't work. Once launched it didn't pick up any FM signal, whatsoever, and I've had to kill it (there was no way of "clean" closing app, too). Also, FM transmitter was a bit disappointing and didn't pass the music clearly in my car. But I didn't really care about this much, thinking that maybe FM Radio app is broken (software-wise) and FM transmitter is just like that. Now guess what. I gave a try to FM Radio app with new unit and it works! I can easily listen to radio without hassle. Also, FM transmitter works like a charm - passes music to my car stereo without a single squelch! Might not be connected at all, but I thought to share that observation so it might give additional lead to follow...
Glad you got it fixed Dawid, are you located in the UK by any chance? I'm going to send mine to get repaired and would like to receive a replacement aswell. How did you send it back to Nokia?
I solved my problem. With the new battery it did not reboot even once. This prompted me to inspect the original dead battery closely and compared both. The original battery seemed to have the contacts not as visible as the new one. With a safety pin I proceeded to bend those contacts outwards. Magic, my N900 started working again with the new original battery too. I tested it shortly and experienced no reboots.
(In reply to comment #285) > I have recently received a warranty replacement unit which thankfully doesn't > suffer from this issue any more, but I made other observation which might or > might not be connected with random reboots. > > With the old N900, I mean the one that rebooted, FM Radio application from > Extras-Testing didn't work. Once launched it didn't pick up any FM signal, > whatsoever, and I've had to kill it (there was no way of "clean" closing app, > too). Also, FM transmitter was a bit disappointing and didn't pass the music > clearly in my car. But I didn't really care about this much, thinking that > maybe FM Radio app is broken (software-wise) and FM transmitter is just like > that. > > Now guess what. I gave a try to FM Radio app with new unit and it works! I can > easily listen to radio without hassle. Also, FM transmitter works like a charm > - passes music to my car stereo without a single squelch! > > Might not be connected at all, but I thought to share that observation so it > might give additional lead to follow... > I can confirm the radio part. Got the radio working once but after that plain silence. Even with vanilla emmc + just flashed os.
(In reply to comment #285) > With the old N900, I mean the one that rebooted, FM Radio application from > Extras-Testing didn't work. [...] > Also, FM transmitter was a bit disappointing and didn't pass the music > clearly in my car. [...] > Now guess what. I gave a try to FM Radio app with new unit and it works! I can > easily listen to radio without hassle. Also, FM transmitter works like a charm > - passes music to my car stereo without a single squelch! > > Might not be connected at all, but I thought to share that observation so it > might give additional lead to follow... Can't confirm this observation. My device reboots all the time (which can be 'fixed' by disabling off-mode) but there are no problems with current version of radio or FM transmitter. With earlier radio versions I also came across some problems (sometimes no station found, not even noise heard) but they clearly seem to be related to the early dev state of the radio app and are fixed in latest version.
Just got a replacement unit from Nokia USA (sent in for other reasons than this issue), and the new unit has been constantly rebooting cat /proc/bootreason gives me 32wd_to Its happened while typing out an SMS, trying to start a first MfE sync, scrolling through the application manager...basically "anything & everything" as the initial bug reporter.
(In reply to comment #284) > (In reply to comment #282) > > Brand new n900, just arrived yesterday, vanilla software. Started reboot itself > > like once every 20 minutes. Reboot happens with or without wifi on, doesn't > > seem to have anything to do with battery, and bootreason said 32wd_to. Once it > > even happened when I was not doing anything with it (in X-Terminal, but not > > typing or running anything). > > Another day's use seemed to confirm that: > 1. all reboots had something to do with touchscreen - if I stayed in x-terminal > running irssi for hours, i.e. only keyboard typing and no touchscreen use, it > never rebooted once. > 2. all reboots so far happened when I was touching the touchscreen. If I was > careful with the touchscreen, e.g. one touch at a time and wait for a bit > between touches, reboots appeared very rarely. If I was touching fast on the > screen, reboots became much more frequently. > I think so cause when i play majhong, it reboot easyly.
Created an attachment (id=1848) [details] sp-oops-extract before turning off enable_off_mode Seemed like a NULL pointer dereference which usually indicated software bugs instead of hardware defects - so I'm holding back from returning my N900 in the hope that a software update would solve it. Testing with enable_off_mode off now.
(In reply to comment #76) > I have ordinary phone (not developers edition, but one bought from Nokia > Online). It has polish language version and firmware 1.2009.42-11. I have > ForecaWeather widget installed and active. > > It reboots with 32wd_to as result. The reboots happen when using WiFi in my > home. Currently I have no possibility to check other WiFi access point. > > I had one reboot when phone was connected to WiFi but I was not transmitting > any data - at that time I was removing many items from calendar (result of bad > import of ICS file). All other reboots happened when using WiFi. The mostly > happen when I am watching some short flash movie, for example at BBC pages. One > reboot happened after about 20 minutes of conversation via Skype. Usually > reboots happen about 15 to 20 minutes of web surfing (without breaks). If I > make breaks (e.g. watch some pages for few minutes, read book for quarter, then > again watch some pages) it takes more time to reboot. > > Two days ago I was experimenting. Changing WiFi settings to 10mW from 100mW did > not help much. Changing power settings from maximum to medium also did not > remove reboots. But after disabling WiFi power saving (in Advanced) I did not > have reboot for about half an hour; however during that time battery level > dropped for about 20-30% and top of device (where, according to manual, WiFi > antenna is located) got rather warm. I was still able to touch it, but decided > to turn WiFi power savings on again. > > During all resets the screen went very dark with Nokia logo, then five-points > animation, then Nokia animation (with connecting hands and sound) then again > five points, and normal desktop. Only once notification diode went white and it > looked like normal cold start, with PIN question. > > I believe that at least in case of my device reboots are connected to WiFi - > when I was not connected to the WiFi and was watching movie from the flash, I > did not have reboot. > This may be related to bu 6615
I can confirm after device replacement random reboots never happend anymore, device is rock stable.
(In reply to comment #294) > I can confirm after device replacement random reboots never happend anymore, > device is rock stable. > Why are you fooling that the restart bug is software related?! It's obvious that you're wasting your time by not returning your defective units back to Nokia. Don't you see that nobody can solve this issue with software update?! This "bug" is not even assigned to a technician?! It's obviously a bad batch of memory chips in some of the N900 devices. Trust me!
I think so because if it was software, every N900 would have. I hope that Nokia recognize the problem and change every N900 who have this "bug"
Mine mainly reboots when im browsing the web or composing a txt message. Ive noticed that before it reboots, while im in the middle of typing a message, the simcard fails (i get a simcard icon with a red line across it instead of the signal indicator) then the screen locks up for a few seconds then the phone reboots. Could be something to do with losing 3g connectivity?
(In reply to comment #292) > Created an attachment (id=1848) [details] [details] > sp-oops-extract before turning off enable_off_mode > > Seemed like a NULL pointer dereference which usually indicated software bugs > instead of hardware defects - so I'm holding back from returning my N900 in the > hope that a software update would solve it. Testing with enable_off_mode off > now. Three days without a single reboot, once I disabled enable_off_mode, so this looked like an effective workaround to me. However, the battery now runs out much quicker - I almost have to charge it every day; clearly it's not a long term solution. The exact cause is still unknown, but I now tend to believe that it's somewhat related to the hardware since people are reporting that their replacements work perfectly. I guess I'll have to argue with Nokia and Amazon tomorrow for my replacement. This has ruined my Christmas - receiving a phone, after endless delays and anxious waits, that reboots itself every 20 minutes or so, and having to google around for a workaround on Christmas and then after finding a workaround having to charge the phone daily. I've been a Linux kernel programmer for ten years, no stranger to troubleshooting and fixing kernel oops and NULL pointer dereferences. Looking at the NULL pointer panics happened on my phone and a couple of reports from others, and considering how easily it is to trigger this auto reboot (from my own experience and others' reports), I tend to believe that Nokia hadn't done any real serious testing on the production units at all, before rushing them to the hands of the customers. Nokia, this is clearly an unfinished product. An open Linux-based phone (Android is NOT, only the kernel part of it can be called Linux) on which users could install software freely is a great idea to me, and the Maemo UI (and stuff like telepathy) looked like a promising platform. However, it'd only ruin your reputation by selling unfinished prototypes to customers and not responding promptly to serious issues like this. Yes, it's Christmas, your managers and developers need to enjoy their vacations - fair enough, but it's very unfair to rush unfinished stuff to customers and leave them in the cold to frustrate over the Christmas. Instead of a refund, I'll still get a replacement, because N900 still remains the only choice for people who want an open Linux phone that can be used freely (in terms of choice of carriers to use and applications to install).
> so please explain and be specific. AFAIK the issue is that sometimes OMAP doesn't come up from the deepest sleep state into state kernel expects, so kernel spins waiting (until HW watchdog reboots the device). If I understood correctly (couldn't verify as people are still on Xmas vacation), the most effective workaround in kernel so far seems to be toggling this state again (whatever that means) as that seems to get the HW to the expected state. The exact reason why the issue happens, what exactly triggers it, how to reliably trigger it and why toggling the state again fixes it is not known yet. It's being investigated (not by me, I'm happy I don't need to do debugging with an oscilloscope). How often it happens seems to vary greatly between people, according to comments here some get it sometimes even several times per hour (it seems to happen more easily just after reset/reboot), but most people never get it. However, there's not enough data to say whether it's more of a binary difference (some devices or environments have/cause it, some not) or a sliding scale (triggering just being rarer on others). This is partly because there may also be other, much rarer 32wd_to reboot reasons. The workaround we're internally testing will help if disabling the off mode helps. If one is still getting 32wd_to reboots with off mode disabled, and they're not due to an oops, then it's possible that this workaround isn't enough to get completely rid of the reboots. (I've been last week testing device that previously rebooted within hour which has now uptime of one week, so the the workaround seems effective and it doesn't decreasing the use-time at all.) Btw. Of the other devices using Omap3: http://en.wikipedia.org/wiki/Texas_Instruments_OMAP#OMAP3 Only Droid is using fairly up to date Linux kernel like N900 does. I'm not sure whether it uses OMAP3 power saving features as extensively (e.g. Beagleboard doesn't), but at least quick googling found some reports about frequent random reboots. Does anybody know about Droid Omap3 power management feature usage extent and whether it has similar issue as described in this bug? (In reply to comment #281) > 1) Could we be dealing with a defective bunch of batteries (no everybody > experiences this problem) + bad power management? Were the reboots in your case also due to 32wd_to? If battery disconnects & reconnects, the /proc/bootreason should be "por" (power on reset), not 32wd_to... (In reply to comment #292) > Created an attachment (id=1848) [details] [details] > sp-oops-extract before turning off enable_off_mode > > Seemed like a NULL pointer dereference which usually indicated software bugs > instead of hardware defects According to our internal statistics we've never had an oops like this and even ones involving kfree happened only before the sales release you're using. So, unless your oops is related to some unrelated internal kernel memory corruption for which some of the earlier attached oopslogs contain indications (SGX & DSP related ones which we've (rarely) encountered also internally), we don't have means to reproduce it. If you can reproduce it later on, please report another bug. (In reply to comment #297) > Mine mainly reboots when im browsing the web or composing a txt message. > Ive noticed that before it reboots, while im in the middle of typing > a message, the simcard fails (i get a simcard icon with a red line across > it instead of the signal indicator) then the screen locks up for a few > seconds then the phone reboots. This seems different issue from the one the others are suffering from. Could you file a separate bug about it with the details about your SIM card and your operator?
(In reply to comment #162) > (In reply to comment #155) > But that kind of frequent reboot behavior listed here is not normal device > behavior. For example the device I use daily (with light usage) hasn't had any > reboots in weeks. If you get these 32wd_to reboots constantly and reflashing > doesn't help, you could consider getting a replacement for it. After some experimentation with disabling power management and re-flashing the device I ended up getting a replacement unit as Eero suggests above. Restored backup in the new device and have now uptime of more than 5 days. So at least in my case it was something wrong with the HW as the installed SW, firmware, SIM-card etc. are identical compared to the unit that was rebooting more than 15 times a day.
I'm also getting frequent reboots with my Maemo Summit Loan N900. But I do have several repositories enabled.
(In reply to comment #287) > I solved my problem. > > With the new battery it did not reboot even once. > > This prompted me to inspect the original dead battery closely and compared > both. The original battery seemed to have the contacts not as visible as the > new one. > > With a safety pin I proceeded to bend those contacts outwards. > Magic, my N900 started working again with the new original battery too. > > I tested it shortly and experienced no reboots. > This happens all the time on my N95 8GB extended battery I bought off of ebay until I get a thumb tac and press the two gold metal pieces in each slot together tighter and reinsert it into the battery compartment. Since you mentioned it I now want to see what the terminals on my battery looks like in the N900. I opened it up and looked and it seems like they are close enough together to get a good snug fit when inserting into the N900 so that it will make contact on N900 power termianls although they do move a lot from side to side so there is a lot of give. This could be a real issue for some people having reboots. Please everyone having reboots issues pay attention if your reboots are happening when there is a sudden jolt or tap to the device, you could have QA issue on the battery terminals losing contact with the pins in the N900 when you suddeny jolt or tap it. But this is not my issuie. . Seems mass manufactured A suddne jar or tap on the back of the device will cause a reboot.
I believe my reboots fall in the "heavy use" case scenerio I got my N900 12/23 and used it a lot, typical use is listening to music while surfing the web, I was doing that a lot. I very much enjoyed my device with virtually no problems. The only other thing i was doing was changing backgrounds and adding and removing widgets (mostly ap news and tune wiki) on the desktop to demonstrate to people the N900. I downloaded a few wallpapers to documents then used file manager to transfer them over to images folder. I had brigthness all the way up and lockscreen at 30 secs. I had omweather widget set to update every 4 hours based on gps location, gps enabled, wifi disabled to save battery and since I am on AT&T I can only use edge. I installed first and second day qik, bounce, that office viewer thing, Gonvert, Copernicum, Mirror, Recorder, Petrovich, xournal, omweather with two icon sets, zoutube, liqflow, adblock, fm transmitter widget, ogg and decoders support. No unexplained problems experienced excpet I only had 1 or 2 reboots up until the 27th morning. On the 26th I tried to install mojopac from http://www.ringcube.com/portal/content/ and it failed and I went on without looking what files and folders it stuck on to my N900. No problems still except for play button on media player widget not working (known issue thats fixed). But 27th about noon I was in a motel and I started to install some more apps using app manager. I installed open vpn, open ssh client, fm radio, cpumem-applet, systeminfowidget. I played with fm radio for a while and could only hear my own voice from the microphone on the headphones and I could barely hear the radio. I put the system info widget on the desktop and stuck it back into the wall charger and looked at talk maemo for a little bit then closed it and watched motel tv until 3:30pm. I put the media player on and went to work. When I got to work I started to try to show the N900 to people and thats when I started getting cosntant reboots. Leaving the music playing and surfing or opening up/scrolling on other tasks I started getting reboots cosntantly. This kept happening the next 12 hours and i kept trying different things to get rid of the problem and then I started paying attention to cpu usage on task bar and widget and it was at 4 bars on task bar and it seemed widget was lagging behind task bar report by 2 seconds saying 100% 2 seconds after taskbar indicates full 4 bars. I tried the following actions in the following order. 1) Remove all widgets from desktop accessing the web except for omweather which for some reason was now showing question marks on it (not updating). I tried removing and putting it back to desktop and force updating it from setting on applet and it won't update. I still leave it there cuz I want to see if it will change. Reboots are stil happening when i use browser and music or just even browser or media player alone and it matches when there is 4 bars on cpu usage on task bar. 2) I suspect fmradio, open ssh client and open vpn first so I uninstall them since this is a old prblem and those are the oldest apps, turn it off, take out the battery, put it back in and then turn it on again. But before I uninstall them I look in my menu system everywhere for the open ssh client and openvpn icons to verify they are installed and they are not there! I can't find the icons for those 2 apps but they showed as icons on uninstall option in app manager. I try to surf the web and listen to music and still constant reboots. Reboot still matches CPU at 4 bars on task bar. 3) I uninstall systeminfo widget, turn it off, take out the battery, put it back in and don't turn it on this time but plug it into the wall charger and let it sit for one hour and then I turn it on and it's fully charged all the way down from 25% (huh? that's fast) Now I turn it on for the next couple hours when I have time I grab it and try to do something (surf web, play music) and for the first time I see the "slide to unlock screen" which I have never seen before. Wow nice screen, How does it trigger? 4) I start using it, I'm still getting random reboots matching 4 bars on cpu usage on task bar and when I have just touched screen but they are not happening as frequent. Now I am noticing so many things are putting cpu usage at 4 bars. I don't know what to do. I just think and work. 5)When work is almost over at 5am I had a bright idea, what if those files mojopac stuck on my N900 is screwing up installs/app manager and OS. I head to the train station on my electric bike. When I get there I look at the files using file manager and delete all files I think came from mojopac. I see 5 or 6 folders, I select them all and delete. I quickly see 3 hundred and something files deleted. I turn it off and back on and browse the internet for about 20 minutes, with no reboot and seems like cpu usage is staying low more often now. 6) I get home and open up 5 tasks at once and use it for about 5 minutes and come to this website here to see the issue and what all of you have done. While reading this page I uninstall foreca installer. I finally force omweather widget to update by removing it and then going to the app itself and repeatedly trying to get it to update by gsm on my gps location then I re add the widget to my desktop and It finally updates but there was a 1 minute lag between the app showing update and the widget (I didn't noitce it was showing I am in the wrong city) and then I let it sit there with those open apps 5 and I think I got it licked so I start typing on talk.maemo.org then it reboots. I hear the music go off from the headphones. I give up, I'm sleepy, I pass out. 7) I wake up 1:20pm and continue reading this website here and this issue and what all of you have done. While reading this page I see proper FHS structure http://www.pathname.com/fhs/pub/fhs- 2.3.html I look there and compare to my N900 using file manager and still see a directory called temp so I delete that directory. Then i use browser and type in file: and see whats there. I see a bunch of folders and only two files omweather.xml 13kb and fb-progress.pid 1kb are those supposed to be there? I don't know. I Install crash reporter app as asked by adding repo and installing, then I take the battery out, press the little gold pins together so it fits more snug against power terminals and then i put it back in turn it on and plug it in to charge. No more reboots and I've been multi tasking for a few hours now.
(In reply to comment #303) > I believe my reboots fall in the "heavy use" case scenerio Aaron, were your reboots of the /proc/bootreason = 32wd_to type? If not, they're not related to issue discussed in this bug. If yes, can you provide the contents of your /dev/mtd2 file?
greetings. I got my N900 on 23rd Dec, and immediately had random reboots - with or without SIM card, with or without network connectivity (3g, wi-fi, gprs). seems independant of activity, mostly while browsing, but also when sending SMS, browsing applications, even looking a device settings. reboots approximately 4-5 times an hour - unuseable... always bootreason is wd32_to. I set the enable_off_mode = 0 (permanent approach) and since that I've had 10+ hours solid use (browsing, GSM calls, radio transmitter, SMS, games etc) without a single reboot. The fix sounds promising, is there any update on this - is there any chance that this fix is holding up the next firmware update? if not, will this fix, when confirmed/tested, be pushed out quickly by itself???
FYI: I'm having a new device to replace the one I sent to service.
(In reply to comment #304) > (In reply to comment #303) > > I believe my reboots fall in the "heavy use" case scenerio > > Aaron, were your reboots of the /proc/bootreason = 32wd_to type? > > If not, they're not related to issue discussed in this bug. > > If yes, can you provide the contents of your /dev/mtd2 file? > You asked for a reproducible reboot scenerio. I have given you that. Do what i did and you get reboots. How can I know if it is 32wd_to if i am no longer having them? I had no idea how to find out if it is 32wd_to until I read this bug page. I have been waiting for the next reboot to see if it is 32wd_to but I'm not getting them anymore. I clearly explained all steps I took to undo it and to cause it in the first place. In order to eliminate other possibilities that the end users are reporting it as 32wd_to and it is not or possible causes or reason for it I have told you here in an effort to help. I thought it would be very useful for me to tell you in detail all the steps I did and undid to cause and undo reboots problems. How can this not be related? You have said yourself this issue is complicated because it has 3 or 4 possible causes/issues related with it. Tell me how to provide the contents of /dev/mtd2 file because I am not a programmer. I installed crash reporter like you asked on this bug page. I am waiting for next reboot so i can type in cat /proc/bootreason and cat /var/lib/dsme/stats/* but I haven't had any more reboots. Are you saying you want me to open a new bug called, "trying to install mojopac and then installing apps through app manager causes frequent reboot problems related to heavy cpu usage." That sounds like quite a long title for a bug and you'd still need the info here.
(In reply to comment #307) > You asked for a reproducible reboot scenerio. I have given you that. Do what i > did and you get reboots. If it was that easy all bugs would be fixed a few days after reporting... > Tell me how to provide the contents of /dev/mtd2 file because I am not a > programmer. See comment 184.
After a week with no random reboots that I can remember, I suddenly had four in the last 24 hours. All 32wd_to, and none of them had any oopses. Two of them occurred after tapping the task manager screen to bring up an incoming SMS or IM. One occurred while composing an SMS and listening to music. The last one happened when an alarm went off this morning . . . the N900 played the first little bits of the alarm, then repeated it several times (like as if the sound output was "jammed"), then rebooted. My N900 has been running with off mode disabled for the last 10 days or so (see my comment 266). The only thing I have done different recently is setup my email account. I will try turning off "Update automatically" in the email settings in case that makes a difference.
I'm experiencing the same thing as John Steele Scott, almost a week without probs and suddenly it reboots a lot (eventhough i did the enable_pff_mode fix). I'm actually trying to get a replacement.
(In reply to comment #308) Ok I've gotten only 2 reboots since last I posted. I removed all things related to omweather. my reason was 32wd_to i typed in /var/lib/dsme/stats/* in to xterminal and what i got was /usr/sbin/browserd -d: 1 But what was weird was when I clicked on xterminal the app manager opened up and acted like it was intalling xterminal when I know for sure I already had the program installed because I've clicked on it before and watched it open up.
After a reboot caused by 32wd_to my sim is no longer recognized by both the N900 than by any other phone.
I've noticed something interesting. I replaced my T-mobile USA SIM card prior to getting my replacement N900. I also have a functioning AT&T USA SIM card. If I pop in the T-mobile SIM card, the N900 reboots quite often. However, with the AT&T SIM card, the system is pretty stable. Could this be a SIM card issue? (Even though I've noticed with other users that they aren't even using SIM cards). The previous N900 I had worked fine with my very old Voicstream SIM card (before T-mobile bought out Voicestream).
(In reply to comment #313) > I've noticed something interesting. I replaced my T-mobile USA SIM card prior > to getting my replacement N900. I also have a functioning AT&T USA SIM card. > If I pop in the T-mobile SIM card, the N900 reboots quite often. However, with > the AT&T SIM card, the system is pretty stable. Could this be a SIM card > issue? 3G on T-Mobile eats more power. You don't have 3G wth AT&T.
Power draw shouldn't cause a reboot/crash. Just after I posted my follow up, the N900 crashed with the AT&T sim. If this is not a software problem, which many suggested it isn't, it would be nice to get a confirmation on it so I can just send it in for a replacement.
(In reply to comment #312) > After a reboot caused by 32wd_to > my sim is no longer recognized by both the N900 than by any other phone. > Yeah, crash of the n900 is not a problem of the sim (i have vodafone)... now in offline state the device restarts anyway probably also because I'm using the wifi all the time since he knocked out the sim and is no longer viewed by any device. --->to laugh...<--- after having spent about 500 € can i do a legal action for take back the 10€ for replacing the sim card? LOL
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.
I have a question here: why does it happen only with several devices? If it is only a firmware bug I would expect that all the devices will have the same problem. Anyway, I can wait for a new firmware but if you can assure that the new version will solve our problem (32wd_to) avoiding to send it back to Nokia. Can anybody confirm it?
(In reply to comment #318) > I have a question here: why does it happen only with several devices? If it is > only a firmware bug I would expect that all the devices will have the same > problem. > > Anyway, I can wait for a new firmware but if you can assure that the new > version will solve our problem (32wd_to) avoiding to send it back to Nokia. > > Can anybody confirm it? > this has been discussed several times withing this bug report. thanks for further spamming and making finding of information more difficult. and all this because you just didn't read all the comments..... gg
Set OMAP power saving - see bug 6615: > The SmartReflex power saving feature of the OMAP processor is disabled by > default on the n900. To enable it: > > echo 1 > /sys/power/sr_vdd1_autocomp > echo 1 > /sys/power/sr_vdd2_autocomp > Set it, around 6h idle and some web was OK, then start seting up email account and got HW watchdog reboot. Before that never seen this kind of reboot (I have N900 a month). But it was my first work with E-mail client. "cat /var/lib/dsme/stats/*" shows /usr/bin/mafw-dbus-wrapper mafw-gst-renderer: 1
I set the two smartreflex controls to 1, and then tried both my IMAP account and (broken due to another bug) Exchange sync (Google) account. No reboot, current public firmware. Wonder why this isn't on be default though...
(In reply to comment #300) > (In reply to comment #162) > ...... > After some experimentation with disabling power management and re-flashing the > device I ended up getting a replacement unit as Eero suggests above. > > Restored backup in the new device and have now uptime of more than 5 days. So > at least in my case it was something wrong with the HW as the installed SW, > firmware, SIM-card etc. are identical compared to the unit that was rebooting > more than 15 times a day. I can confirm this too. My original N900 kept rebooting itself about once every 20 minutes with "32wd_to" (comment 282) and disabling off mode worked around the problem completely. Then I got a replacement unit and restored backup from the 1st one. The replacement unit has been working perfectly for about 5 days - rather heavy usage, I intentionally stressed it with many concurrent applications, and everything else is the same (SIM card, wifi, and so on). It looked like at least some of the reboot problems had something to do with the hardware.
(In reply to comment #322) > (In reply to comment #300) > > (In reply to comment #162) > > ...... > > After some experimentation with disabling power management and re-flashing the > > device I ended up getting a replacement unit as Eero suggests above. > > > > Restored backup in the new device and have now uptime of more than 5 days. So > > at least in my case it was something wrong with the HW as the installed SW, > > firmware, SIM-card etc. are identical compared to the unit that was rebooting > > more than 15 times a day. > > I can confirm this too. My original N900 kept rebooting itself about once every > 20 minutes with "32wd_to" (comment 282) and disabling off mode worked around > the problem completely. > > Then I got a replacement unit and restored backup from the 1st one. The > replacement unit has been working perfectly for about 5 days - rather heavy > usage, I intentionally stressed it with many concurrent applications, and > everything else is the same (SIM card, wifi, and so on). > > It looked like at least some of the reboot problems had something to do with > the hardware. Does the new n900 have the same firmware and the same power settings?
(In reply to comment #323) > ...... > Does the new n900 have the same firmware and the same power settings? Yes, same firmware version (as shown in settings->about product); same /etc/pmconfig. Is there anything else to check?
(In reply to comment #306) > FYI: I'm having a new device to replace the one I sent to service. > 6+ hours of random usage with new device, zero reboots. so i can confirm that this is somewhat hardware related. new device has same 42-11 sw.
As a data point, when hitting bug 6868, which keeps the device from entering C4 as well, rock solid. Otherwise getting 1-4 32wd_to reboots daily on my device.
I had problems with reboots. After installing software to send reports and core files to maemo.org crashes seemed less frequent; instead applications were killed with signal 11 (mostly pylse-audio and browserd) - but crashes happened once every two days or so. At the same time I did not go to YouTube to avoid crashes, so it is not the proof. When I was at the CCC in Berlin, I tried to use WiFi there. Wireless access was not reliable and my device started rebooting again, esp. when it lost connection to the net. But reboots were not only caused by WiFi - it rebooted twice without any connection (only phone, without any active talks or data connection), just during reading web page which I downloaded later and left browser in background. After coming back home, with more reliable WiFi, frequency of reboots decreased. Two days ago I read description of bug 7633 (SmartReflex). I decided to turn it on by changing 0->1 in appropriate lines of /etc/pmconfig. It did not caused instability but at the same time did not helped - phone rebooted after 15 minutes of watching YouTube movie. So yesterday in the evening I turned off enable_off_mode in /etc/pmconfig, rebooted phone (power button->Reboot). It had about 50% of battery in the evening, and it survived the night and most of the day on that battery. I was able to watch the entire YouTube movie online over WiFi (1:20:00) without any reboot. After 40 minutes of the movie I had to connect the charger and rest of the movie watched while charging. During charging I had phone call - and then phone started behaving in unresponsive manner. GUI was slow (because of it I rejected call instead of accepting it), I was not able to swipe from desktop to desktop. At the same time I was able to use the hardware slider to turn on and off the screen - and it helped with responsiveness. I was still not able to swipe through desktops but was able to use menu (top left corner). I run the terminal and run uptime - load on system was about 3.70. But top did not show anything wrong and soon load started to decrease. I then decided to make phone call, finished it, returned to watching video (YouTube page was still opened). I finished watching it and left it charging. In summary: after enabling SmartRefles and disabling OffMode my phone seems much more stable - it does not reboot during activities when it was restarting earlier. Battery life does not seem much worse. At the same time it is only one day of this configuration - so I intend to observe it closely.
If you do the pmconfig change, you can still invoke the random reboot by sending a bluetooth file with Petrovich (at least in my case).
Created an attachment (id=1935) [details] mtd2 from my n900
(In reply to comment #328) > If you do the pmconfig change, you can still invoke the random reboot by > sending a bluetooth file with Petrovich (at least in my case). > I also enabled the OMAP's power saving feature, like in bug 7633 https://bugs.maemo.org/show_bug.cgi?id=7633 and set enable_off_mode to 1. The phone is more stable, but still reboots albeit much much less often, and is therefore usable. Battery life still sucks but I have now removed OMweather and RSS reader and set wireless scan to none (will see how this goes). email set to update every 15 minutes. I can also get it to crash on command by sending a file using bluetooth and petrovich. Seems like a difference in silicon manufacturing with which the drivers cannot cope - I suspect because the OMAP is new the driver is not complete for all possible FSM states.
Having random reboots about 1, maybe 2, times a day. Would like to help if possible so feel free to ask me for info since I get a reboot fairly often.
My issue was solved completely when I exchanged the phone. The new phone is running the same firmware as the old, it just doesn't reboot itself. If you are still having trouble, ask Nokia for a replacement.
And we've no information from Nokia Boys...
it's nothing new that this issue is at least related to specific devices, i've reported that in comment #211 in mid-december. i wonder how much effort will be put into fixing a bug in software instead of replacing defective hardware.
(In reply to comment #305) > > The fix sounds promising, is there any update on this - is there any chance > that this fix is holding up the next firmware update? if not, will this fix, > when confirmed/tested, be pushed out quickly by itself??? > This question seems to have been missed (or ignored?) Can NOKIA please give some indication as to whether this "fix" that is "being tested internally" is actually being progressed or not? If not, then can NOKIA give confirmation that this problem is indeed hardware, and faulty handsets are to be replaced without question.
yes cause i love the N900 and don't want another but i want one who don't reboot at all...
(In reply to comment #335) > (In reply to comment #305) > > > > The fix sounds promising, is there any update on this - is there any chance > > that this fix is holding up the next firmware update? if not, will this fix, > > when confirmed/tested, be pushed out quickly by itself??? > > > > This question seems to have been missed (or ignored?) > > Can NOKIA please give some indication as to whether this "fix" that is "being > tested internally" is actually being progressed or not? If not, then can NOKIA > give confirmation that this problem is indeed hardware, and faulty handsets are > to be replaced without question. > I have the same question! I bought my N900 from Bahrain (Middle East) and I will move to the United States next week. So I want to know if this is a hardware issue (not a software problem) cause I will replace the device here!! Will Nokia US replace it? (I don't think so!!)
Contact Nokia Customer Support for this but don't spam this bug report, please. It's off-topic and just wastes everybody's time by triggering emails.
Reflashed firmware on device. No reboots for 24 hours. With normal use of mail, web, phone, notes. Only third party apps installed: load-applet, Simple Brightness Applet. Noticed mail wasnt sending from either of my email accounts so I went to edit both mail account settings, specifically SMTP server. Was having trouble getting phone to connect to SMTP servers. Tried my server, my ISPs server, Gmail's server. Was editing the SMTP settings, trying to send, then editing again. Had 2 reboots while adjusting outgoing server settings. Put device in airplane mode to try to prevent reboot just in case it was due to phone being connected to servers/net. Payed closer attention. Had third reboot when I touched the SMTP server address and tried to edit it. Noticed keyboard backlight had been been off indicating perhaps device was sitting momentarily and shut off keyboard to save power. Was unable to reproduce in about 10 tries.
(In reply to comment #339) > Reflashed firmware on device. No reboots for 24 hours. With normal use of > mail, web, phone, notes. Only third party apps installed: load-applet, Simple > Brightness Applet. > > Noticed mail wasnt sending from either of my email accounts so I went to edit > both mail account settings, specifically SMTP server. Was having trouble > getting phone to connect to SMTP servers. Tried my server, my ISPs server, > Gmail's server. Was editing the SMTP settings, trying to send, then editing > again. Had 2 reboots while adjusting outgoing server settings. These were immediate reboots > > Put device in airplane mode to try to prevent reboot just in case it was due to > phone being connected to servers/net. Payed closer attention. Had third > reboot when I touched the SMTP server address and tried to edit it. Noticed > keyboard backlight had been been off indicating perhaps device was sitting > momentarily and shut off keyboard to save power. This time the device froze for about 2-3 seconds, then rebooted > Was unable to reproduce in > about 10 tries. >
Sorry, last post. Came out of airplane mode. Went into Notes to let device keyboard go to sleep. As soon as i saw keyboard sleep, i tapped screen or keys to wake keyboard. Did this about 10 times with no reboot. Went into X term and typed a few commands. Keyboard went to sleep. Then the screen too. Then I noticed it rebooting a few minutes later, perhaps when it went to deep sleep. 32wd_to as usual.
...I lied... Sending back to Nokia. Reboot combined with weak FM transmit power, patchy FM receiver performance, and a strange static/interference issue with seemingly generic stereo/mic headsets leads me to believe I just got a bad device.
After some trial and error I found a permanent solution to this problem. I returned my phone to Dell and got a nexus one. The new phone is rock solid. Havent had a single reboot since I got it. sorry to say I am going away from the Nokia camp. I have owned an n95 and an e71 and have been a happy camper so far. What bugs me most is that no one from Nokia has come up and said - yes this is a hardware problem, send the phone back , we will replace it for you. Or we know its a problem, we are working on it. Instead making the users try out things with settings. Guys - thats QA job. I dont expect this from a $500+ device. I know this post didnt add any value to the bug, and I am sorry about that. But I have been following this for so many days hoping for someone from Nokia to show up but I have had it.
(In reply to comment #343) > After some trial and error I found a permanent solution to this problem. I > returned my phone to Dell and got a nexus one. The new phone is rock solid. > Havent had a single reboot since I got it. too bad you can't be banned retroactive from bugtracker... > > sorry to say I am going away from the Nokia camp. I have owned an n95 and an > e71 and have been a happy camper so far. What bugs me most is that no one from > Nokia has come up and said - yes this is a hardware problem, send the phone > back , we will replace it for you. Or we know its a problem, we are working on > it. Instead making the users try out things with settings. Guys - thats QA > job. I dont expect this from a $500+ device. > > I know this post didnt add any value to the bug, and I am sorry about that. > But I have been following this for so many days hoping for someone from Nokia > to show up but I have had it. > you should have read all the comments before instead spamming one more yourself. So thanks for further ruining other peoples changes to get this issue fully figured out asap. Hope your nexus one will break down and spends couple months in service in exchange to tie the karma... is it so hard to use http://talk.maemo.org/showthread.php?t=35055 for chitchatting? this url has been mentioned probably third time now.....
-Does the newly released firmware (1.2009.44.1) fix the problem? If it does, what about battery/power consumption? -Has this bug tracker anything to do with Nokia or are we all a bunch of unofficial hackers? I ask because this old, critical and sever reputation damaging bug is still shos up as NEW/Unassigned. How Can that be if we are told Nokia is working on the issue? It gives the probably wrong impression that nothing is being done.
I don't think the 44-1 upgrade will have addressed this (my understanding is that this 44-1 upgrade fixes some issues around the upgrade path (I could be wrong however). Regardless, I'm testing now - reset enable_off_mode = 1 and rebooting now - looking for reboots now.
got one 32wd_to reboot easily (browsing around www.maemo.org did the trick!) - just got another as I typed this up - this time, installing "angry birds" from Ovi Store... I'm going to assume that this problem has *not* been fixed. The "unassigned" status of this is worrying - the indication that was given earlier by a Nokia person is that a likely fix was being tested internally - can anyone confirm if this is actually progressing?
Well, my wild guess is that this is solved or worked around with the firmware 1.2009.44-1 in some level. Not very fresh or the latest firmware (as someone said) so I believe that it's not a real bug fix but still, it seems to work for me. There have to be some difference. No random reboots after upgrade and enabling enable_off_mode again. Okay, I have got one browser and flash related reboot but that is something different that I can repeat, related to another bugs. But in general no random non-repeatable rebooting anymore. And now my battery do not run out which is also great! I keep testing but seems to work for now. I am in RnD mode so I am not totally sure if it has something to do also with that. Need to test also this scenario.
definitely not fixed for me - repeated 32wd_to reboots with "enable_off_mode = 1". Returned "enable_off_mode = 0" and rebooted - stable again since, but with this I was (pre 44-1) getting ~12 hours with 40% battery remaining (including usually 1-2 hours browsing on WiFi, 15-20 SMS messages, 10-20 mins GSM calls, 15-30 minutes 3G data browsing, some occasional games/music)
(In reply to comment #347) > got one 32wd_to reboot easily (browsing around www.maemo.org did the trick!) - > just got another as I typed this up - this time, installing "angry birds" from > Ovi Store... > > I'm going to assume that this problem has *not* been fixed. > > The "unassigned" status of this is worrying - the indication that was given > earlier by a Nokia person is that a likely fix was being tested internally - > can anyone confirm if this is actually progressing? > I can confirm as well that the problem was not FIXED. I flashed my phone with new firmware and enabled the /etc/pmconfig parameter and got exactly same behavior as before (crashing every now and then). Now i disable again the enable_off_mode and is smooth no crashes.
Can someone point me where i should look in order to configure tools needed to be able to submit logs and dumps for bugs i find on my N900?
(In reply to comment #351) > Can someone point me where i should look in order to configure tools needed to > be able to submit logs and dumps for bugs i find on my N900? Please read this bug report. It has been explained several times, e.g. comment 184, but of course that's hard to find as people continue adding cluttering comments. (In reply to comment #347) > I'm going to assume that this problem has *not* been fixed. (In reply to comment #350) > I can confirm as well that the problem was not FIXED. Of course it's not fixed, otherwise it would be RESOLVED FIXED instead of NEW. Please find out what the "Status" field in bug reports is meant for before commenting. It's only one click away. (In reply to comment #347) > The "unassigned" status of this is worrying - the indication that was given > earlier by a Nokia person is that a likely fix was being tested internally - As this report has become completely unreadable anyway because of unhelpful or even completely useless comments and people not understanding the difference between a bugtracker and a forum, I don't expect any Nokians to comment here as they will receive tons of mostly useless bugmail afterwards. So yes, Nokia is working on this. I've mentioned this before though... If it makes you happier, I can set this to "ASSIGNED". It won't change much though...
(got back from vacation + handled some thousands of mails I got during it.) (In reply to comment #346) > I don't think the 44-1 upgrade will have addressed this (my understanding is > that this 44-1 upgrade fixes some issues around the upgrade path (I could be > wrong however). This is correct. The first upgrade fixes some issues related to package installation&upgrade disk usage[1] and the next upgrade following it (most likely the 51.1 one that also some external people have been beta testing & commenting here in bugzilla) will then provide the real workaround for the off_mode 32wd_to reboots (+ many other improvements). I think after that release this bug can be closed as it fixes the main reboot thing discussed in this bug. The other reboot reasons are either very rare or happen in some specific condition (WLAN issue mentioned by one of above comments). Other bugs should be created for those. [1] See bug 5450. If you flash the release fixing this bug instead of using SSU, you don't need to install the intermediate 44.1 version. Additional bonus of flashing the release instead of using SSU is that the applications & device will start slightly faster and consume less memory (this difference caused by prelinking may not be very user visible, but it's measureble).
(In reply to comment #353) > This is correct. The first upgrade fixes some issues related to package > installation&upgrade disk usage[1] and the next upgrade following it (most > likely the 51.1 one that also some external people have been beta testing & > commenting here in bugzilla) will then provide the real workaround for the > off_mode 32wd_to reboots (+ many other improvements). > I have to take my words back. Also my N900 does random rebooting (32wd_to type) with the latest public firmware (1.2009.44-1) as before. But I have explanation and a bit old information if that gives any value, though the behavior may vary between the different devices. 42-11: Disabling enable_off_mode did help and I was able to use the device. Just for test I also enabled the SmartReflex power saving feature of the OMAP processor though many people said that it will cause also other rebooting issues. Well, I found it very useful. 44-1: After the upgrade, my device worked so that if I enable enable_off_mode and disable the SmartReflex, I will get random reboots so that the device is unusable. This was very much expected behavior. After this I enabled the SmartReflex again. I set both, sr_vdd1_autocomp and sr_vdd2_autocomp to 1 in /etc/pmconfig file and rebooted. I have 1 in enable_off_mode feature (so it's enabled). The point here is that disabling enable_off_mode was only way to keep the device running with 42-11, now it's different. For some reason I don't get random reboots (or it just probably take some days to happen) which doesn't sound very logical. My speculation/value/confirmation is following. When the SmartReflex is enabled, CPU voltage is dynamically adjusted (that's how I have understood the feature) which seems to work so that my CPU usage rate seems to be more active. So I assume that possibility where my CPU of the device will go to off_mode (when enabled, CPU can go to very deep sleep and it should triggered to wake) causing random reboots, will be a bit less than before. I don't know whether triggering here is related just to some series of OMAP3s or to just the kernel drivers but there's always some reason. Sorry spamming.
(In reply to comment #354) > I have to take my words back. Also my N900 does random rebooting (32wd_to > type) with the latest public firmware (1.2009.44-1) as before. But I have > explanation and a bit old information if that gives any value, though the > behavior may vary between the different devices. > > 42-11: Disabling enable_off_mode did help and I was able to use the device. > Just for test I also enabled the SmartReflex power saving feature of the OMAP > processor though many people said that it will cause also other rebooting > issues. Well, I found it very useful. > > 44-1: After the upgrade, my device worked so that if I enable enable_off_mode > and disable the SmartReflex, I will get random reboots so that the device is > unusable. This was very much expected behavior. After this I enabled the > SmartReflex again. I set both, sr_vdd1_autocomp and sr_vdd2_autocomp to 1 in > /etc/pmconfig file and rebooted. I have 1 in enable_off_mode feature (so it's > enabled). > > The point here is that disabling enable_off_mode was only way to keep the > device running with 42-11, now it's different. For some reason I don't get > random reboots (or it just probably take some days to happen) which doesn't > sound very logical. You mean that with the 44.1 release your reboots went away when enabling _both_ off_mode and smartreflex? If yes, that's very interesting... > My speculation/value/confirmation is following. When the SmartReflex is > enabled, CPU voltage is dynamically adjusted (that's how I have understood > the feature) AFAIK off_mode also does voltage changes (with frequency changes), SmartReflex just makes the used voltages specific (fine-tuned) to the OMAP CPU you have in your device.
(In reply to comment #355) > You mean that with the 44.1 release your reboots went away when enabling _both_ > off_mode and smartreflex? If yes, that's very interesting... > Yes, that's what happened. Probably it would be interesting/valuable to hear if it's repeatable with other devices having the bug as well.
(In reply to comment #356) > (In reply to comment #355) > > You mean that with the 44.1 release your reboots went away when enabling _both_ > > off_mode and smartreflex? If yes, that's very interesting... > > > > Yes, that's what happened. Probably it would be interesting/valuable to hear if > it's repeatable with other devices having the bug as well. > Out of interest I tried this also: enable_off_mode = 1 sr_vdd1_autocomp 1 sr_vdd2_autocomp 1 And rebooted - uptime now at 54+ minutes, with most of that time 3G and WiFi browsing to try and elicit a reboot (normally happens within 5 minutes when desired). No reboot yet, looks like something is different since 44-1, as this configuration made no improvement pre 44-1. Is there an advantage to this - will this save battery consumption, better than "enable_off_mode = 0" at least?
(In reply to comment #357) > Out of interest I tried this also: > enable_off_mode = 1 > sr_vdd1_autocomp 1 > sr_vdd2_autocomp 1 ... > Is there an advantage to this - will this save battery consumption, > better than "enable_off_mode = 0" at least? Disabling off mode is what makes the use-time (much) worse, whereas enabling smartreflex can actually improve it a bit. The reason why it's not enabled by default is that it makes many of the devices unstable (see bug 7633).
(In reply to comment #357) > Out of interest I tried this also: > enable_off_mode = 1 > sr_vdd1_autocomp 1 > sr_vdd2_autocomp 1 Also tried it and can confirm that no random reboots occurred during last hours while battery life *significantly* improved compared to the extreme battery drain I experienced before with off_mode = 0.
> Out of interest I tried this also: > enable_off_mode = 1 > sr_vdd1_autocomp 1 > sr_vdd2_autocomp 1 > Following up on this - I've now had 7.25 hours uptime, with varying usage (3g browsing, WiFi browsing, SMS, and a few hours idle time) - battery consumption in that time (measured by "hal-device bme | grep percentage" has only been 10% (71% down to 61%) - better than with "enable_off_mode = 0" - and seemingly equally as stable (so far...)
(In reply to comment #360) > > Out of interest I tried this also: > > enable_off_mode = 1 > > sr_vdd1_autocomp 1 > > sr_vdd2_autocomp 1 > > > Following up on this - I've now had 7.25 hours uptime, with varying usage (3g > browsing, WiFi browsing, SMS, and a few hours idle time) - battery consumption > in that time (measured by "hal-device bme | grep percentage" has only been 10% > (71% down to 61%) - better than with "enable_off_mode = 0" - and seemingly > equally as stable (so far...) I tried this as well, but as soon as I rebooted my n900 it only took about 5 mins of re-arranging the desktop items to get a reboot again. So in my case this is not working at all. While editing the pmconfig file to undo the changes it rebooted again, so I'll just leave my pmconfig looking like this: enable_off_mode = 0 sr_vdd1_autocomp sr_vdd2_autocomp At least this way I can use my phone for one day without recharging it, but so be it.
I'm also confirming - enable_off and the rest are 1. No reboots and good battery use for 10 hours now. :)
I had no random reboots but decided to test SmartFlex reliability. Set sr_vdd1_autocomp sr_vdd2_autocomp in /etc/pmconfig to 1 (enable_off_mode was 1 by default), switch OFF and ON. 1. I got battery charge dropped by 2 points, current still 224 (lshal). 2. I got "jumpy" window behavior - open window and FUNC+BS moves by jumps. "top" doesn't show any CPU consumption by application (sorry, didn't look into kernel times). 3. e-mail agent opens Yahoo mail forever - doesn't stack, but just rotating circle. Network access indicator shows a good 3G or WiFI (I tried both). BTW, one of my Yahoo account in e-mail agent that time doesn't show "Inbox" at all. So, I decided to stop experiment at that point, edit /etc/pmconfig back and OFF-ON. Anything returns to normal - smooth window opening, e-mail retrieved mails... besides battery level, of course.
Additional info - 30min after return to regular /etc/pmconfig setting I discovered that battery indicator advances 1 point up (I didn't charge this 30min, honestly!)
(In reply to comment #364) > Additional info - 30min after return to regular /etc/pmconfig setting I > discovered that battery indicator advances 1 point up (I didn't charge this > 30min, honestly!) The charge battery reports depends slightly also on how much current is drawn from it. So it's possible for it to go slightly up too and if the value was at one of the battery indicator limits, you can see indicator going up too. Btw. it's better to use: lshal|grep batt And check the battery.charge_level.percentage value (I don't think battery indicator is linear, battery charge changes at different speeds at different charge levels).
I have upgraded to 2009.51 and in 2 hours after update (when browsing on WiFi using eduroam network) had 4 reboots. Screen stopped responding to touch, went dark, then dark (without backlight) Nokia logo appeared, LED blinked in white and reboot. After one of the reboots I have lost RSS reader and all widgets on all desktops - everything from desktops went missing except page bookmarks. RSS reader was starting and then not displaying anything except title bar and was not responding to close button or to menu bar. I was not able to change anything on desktop - hildon-desktop was displaying menu bar and reacting to "Ready" ("Gotowe" in polish language settings) but was not displaying menu, not allowing to add or remove widgets, etc. Fortunately i removed .config/hildon-desktop and .osso_rss/cache and everything was OK, and I had only re-add widgets to desktop and reload RSS feeds. I intend to play a little bit with settings from /etc/pmconfig (SmartReflex and enable_off_mode) but I am starting to believe that my phone has faulty hardware.
(In reply to comment #366) > I have upgraded to 2009.51 and in 2 hours after update (when browsing > on WiFi using eduroam network) had 4 reboots. Screen stopped responding to > touch, went dark, then dark (without backlight) Nokia logo appeared, LED > blinked in white and reboot. this doesn't help at all.. first check that /proc/bootreason contains "32wd_to" second, read all comments. the most useful ones have been mentioned multiple times in comments (mainly by A Klapper)...
I can confirm that since the installation of the new firmware 12 hours ago i did not have a single reboot with the famous 32wd_to reason. Before update it used to reboot with no pa tern. I think the update has done something.
(In reply to comment #367) > (In reply to comment #366) > > I have upgraded to 2009.51 and in 2 hours after update (when browsing > > on WiFi using eduroam network) had 4 reboots. Screen stopped responding to > > touch, went dark, then dark (without backlight) Nokia logo appeared, LED > > blinked in white and reboot. > > this doesn't help at all.. first check that /proc/bootreason contains "32wd_to" > > second, read all comments. the most useful ones have been mentioned multiple > times in comments (mainly by A Klapper)... > I never had this issue, but not with the PR1.1 update I have had 5 reboots in the last 12 hours with the 32wd_to reason. Man this update gave me this bug that I formerly never had. I just did an upgrade in place. I might flash the device if this continues.
Setting as fixed in just released w51.1. If you're still getting reboots, but /proc/bootreason is *something else than 32wd_to*, please file separate bug(s) about those (and add comment here about them). If you're still having *32wd_to* reboots, check whether they're caused by kernel oopses: Install sp-oops-extract from the SDK tools repository: http://wiki.maemo.org/Documentation/devtools/maemo5#Installation And check whether you have _new_ oopses (old ones aren't cleared on reflash) by doing: sp-oops-extract /dev/mtd2 (You can also read /dev/mtd2 directly, but sp-oops-extract shows the data in more human-readable form.) If you do have kernel oopses, please file separate bug(s) about them (and add comment here about them) If the reboots aren't due to kernel oopses, take a backup and copy your data on the MyDocs directory to somewhere else, reflash your device with w51.1 release and clean eMMC contents, and restore your backup. If the unexplained 32wd_to reboots still continue daily, you could consider replacing your device. (In reply to comment #369) > I never had this issue, but not with the PR1.1 update I have had 5 reboots in > the last 12 hours with the 32wd_to reason. > Man this update gave me this bug that I formerly never had. > > I just did an upgrade in place. I might flash the device if this continues. David, please check first whether reboots are caused by kernel oopses as explained above (and attach the extracted oopslog or full mtd2 contents here).
(In reply to comment #370) > David, please check first whether reboots are caused by kernel oopses as > explained above (and attach the extracted oopslog or full mtd2 contents here). > Thanks. I did the "enable_off_mode 0" change and it hasn't rebooted since. I have the term "oops" in my /dev/mtd2. I'll attach the contents of my /dev/mtd2. I will try putting "enable_off_mode 1" if this new stablility continues to try and get to the bottom of this.
Created an attachment (id=1986) [details] mtd2 after reboots since PR1.1 I have just dumped my /dev/mtd2 to this text file and not run it through "humanising" app :-). I am on a train head home from work. I can run it through that app if that is needed.
(In reply to comment #372) > Created an attachment (id=1986) [details] [details] > mtd2 after reboots since PR1.1 > > I have just dumped my /dev/mtd2 to this text file and not run it through > "humanising" app :-). I am on a train head home from work. I can run it > through that app if that is needed. You have a large number of different oopses, some of them already mentioned in comments above. One of them about swap and one about page request failing. I have a strong suspicion that some internal kernel memory corruption has actually corrupted your rootfs. I'd recommend you to reflash rootfs and maybe also eMMC, just in case /home ext3 is also corrupted (after taking backup and copying your data to safety). I don't think your issue is related to the main issue discussed in this bug.
Perhaps the Maemo/Nokia team should contact whoever is doing repairs at the Nokia Repair Center in Alabama. I've sent my N900 in for this very issue. They sent back a letter that they could reproduce the issue & was able to fix it. But left a very vague message about the repair: "Connectivity - Problems with short range connectivity e.g. Blue Tooth, IR, WLAN, Cable, Video." So in short, my phone did not get replaced but repaired and went through some final testing & QA process. Once I got the phone back, I flashed it to the latest publicly released firmware PR1.1 USA and its been quite stable for the last 18+ hours or so. I have also checked the /etc/pmconfig and enable_off_mode is set to 1
In reply to comment #367. I know that this bug is about 32wd_to. Look at my comment #76, #78, #102, #183, #327. All my reboots since OTA upgrade to firmware 51 are 32wd_to. My situation now is similar to the one described in comment #369. With firmware 42-1 I had reboot once, twice a day. When I changed enable_power_off to 0 and SmartReflex to 1 (as described in my comment #) I had reboot about twice a week. After upgrading I changed back enable_power_off to 1 and then I had reboot every 30 minutes or so. When I turned it back off (/etc/pmconfig contains enable_power_off 0) I had only one reboot - just after starting Wormux. When I started it again, my device have not rebooted again. Battery life is shorted that with enable_power_off=1, but now device is stable. With firmware 42 I had choice whether to set enable_power_off to 1 (and have occasional reboots) or disable it. Now, with firmware 51 I must keep it disabled to be able to run device. So for me this bug is not RESOLVED FIXED. For comment #370. I heve installed CrashReporter which sends crash reports when application or device crashes. Should I install sp-oops-extract?
I've just updated the firmware to the new pr1.1 firmware, did not change any settings in the pmconfig file (so enable off mode is 1). The phone is now rock solid and had no reboots, sw_rst are expected as they are program crashes (none yet), but no 32wd_to crashes. So PR1.1 in my case HAS fixed the reboot issue. The battery however still doesn't seem very good, but I am using an older battery from my 5800.
(In reply to comment #375) > I know that this bug is about 32wd_to. > Look at my comment #76, #78, #102, #183, #327. > All my reboots since OTA upgrade to firmware 51 are 32wd_to. ... > So for me this bug is not RESOLVED FIXED. The important question after that is, do you get (new) kernel oopses logged to the /dev/mtd2 oops log partition with the 51.1? If yes, this is some unrelated issue, not the one this bug focuses on, and you should file new bugs about those (at least if they continue after reflashing). If you still have 32wd_to reboots, but no oopses, then you may still have this issue. We have one device where the workaround in 51.1 didn't fix the reboots, but we're still investigating whether its reboots are due to the same issue. This device 32wd_to reboots and doesn't log oops, but the issue seems to be related to WLAN, so it may still be unrelated issue (kernel freeze / busylooping triggering HW watchdog reboot can also have other causes like hard to trigger driver/firmware code bug). You might try installing syslog to your device from the SDK tools repository and seeing whether it gets any interesting messages before reboots (the way to find reboot place from syslog is by finding last "Bootup reason" entry and then going back from that until you see syslog restart with many second skip in log timestamps). > For comment #370. > I heve installed CrashReporter which sends crash reports when application or > device crashes. Should I install sp-oops-extract? Crash reporter should indirectly depend on sp-oops-extract, so you should already have it installed (to check, do on XTerm: "dpkg -s sp-oops-extract"). Btw. The crash reports include your device WLAN MAC (e.g. in included "ifconfig" output) so that we can categorize the issues by device. If you mail me your device MAC address (you can see it e.g. from "Settings" application "About product" applet), I could take a look at the issues you've uploaded from your device.
(In reply to comment #373) > (In reply to comment #372) > > Created an attachment (id=1986) [details] [details] [details] > > mtd2 after reboots since PR1.1 > > > > I have just dumped my /dev/mtd2 to this text file and not run it through > > "humanising" app :-). I am on a train head home from work. I can run it > > through that app if that is needed. > > You have a large number of different oopses, some of them already mentioned in > comments above. One of them about swap and one about page request failing. I > have a strong suspicion that some internal kernel memory corruption has > actually corrupted your rootfs. > > I'd recommend you to reflash rootfs and maybe also eMMC, just in case /home > ext3 is also corrupted (after taking backup and copying your data to safety). > I don't think your issue is related to the main issue discussed in this bug. > Thanks. I haven't reflashed, I thought I'd test putting the pmconfig back to default first. I have and I am happy to announce no random reboots. So my issues was straightened out with a few "proper" reboots perhaps. Thanks.
I think I spoke too soon. I have had about 6 random reboots over the last 12 hours :( I have changed the pmconfig file back, see if this effects it positively again. I will attach my latest mtd2 dump as well. I will flash if it shows a FS corruption. I am trying to get this crash-reporter package into my phone. I see it in the repo for the SDK but I need to find it for my phone to help with these logs..
Created an attachment (id=2071) [details] mtd2 dump 20100121 This is my recent mtd2 dump. About 6+ reboots in the last 12 hours. Some 32wd_to and others sw_rst. Often they would come in a bunch, like 2-3 random reboots in a row and then a few others later another 2-3 reboots.
So I have just flashed my rootfs. In restoring the Application List, the phone has rebooted twice, both with a reason: sw_rst I have run a dosfsck on /home/user/MyDocs both from the device and from my PC over USB. What else can I do/check to report more valuable information on this issue? Thanks
(In reply to comment #381) > So I have just flashed my rootfs. > > In restoring the Application List, the phone has rebooted twice, both with a > reason: sw_rst I sympathize, but this bug (see the title) is about reboots with the reason 32wd_to. Please file (or find) a separate bug.
(In reply to comment #382) > (In reply to comment #381) > > So I have just flashed my rootfs. > > > > In restoring the Application List, the phone has rebooted twice, both with a > > reason: sw_rst > > I sympathize, but this bug (see the title) is about reboots with the reason > 32wd_to. Please file (or find) a separate bug. That bug should contain the output of this after the reboot: cat /var/lib/dsme/stats/* To find out which system service termination triggered the reset. And please install Crash reporter so that you can provide more details about the reason why the system service terminated.
(In reply to comment #383) > (In reply to comment #382) > > (In reply to comment #381) > > > So I have just flashed my rootfs. > > > > > > In restoring the Application List, the phone has rebooted twice, both with a > > > reason: sw_rst > > > > I sympathize, but this bug (see the title) is about reboots with the reason > > 32wd_to. Please file (or find) a separate bug. > > That bug should contain the output of this after the reboot: > cat /var/lib/dsme/stats/* > > To find out which system service termination triggered the reset. And please > install Crash reporter so that you can provide more details about the reason > why the system service terminated. > Thanks Eero. Should we take this offline? I did have Crach reporter installed before. A few reports have gone through in the last 24 hours. I'll check if it is still there. I am formatting the /home/user/MyDocs partition now. fsck was run on it several times, but I am wanting to be sure.
(In reply to comment #380) > Created an attachment (id=2071) [details] [details] > mtd2 dump 20100121 > > This is my recent mtd2 dump. About 6+ reboots in the last 12 hours. Some > 32wd_to and others sw_rst. There are many oopses and nowadays kernel normally does sw_rst after oops, but it's still possible that the 32wd_to ones could be caused by the these oopses too. This can happen if there was a bit too much time from the last HW watchdog kicking time before that (AFAIK kicking is currently done at 12 sec intervals with 2 secs margin before device gets rebooted by HW watchdog) and things leading to oops or oops itself prevented user-space HW kicker from working for while. Note that in 51.1 kernel appends to the oops information the product release information so that it's now easy to see from which release kernel they come. New oopses (which were not in your previous oopslog) are from: - BUG at unmap_vmas/release_console_sem -> internal kernel memory corruption? - __mutex_lock_slowpath (called from twl4030_i2c_read) - cpu_v7_switch_mm > Often they would come in a bunch, like 2-3 random reboots in a row and then a > few others later another 2-3 reboots. There have been some indications (comments in SGX HW recovery resets bug) that a reboot might not reset the device state fully, at least sometimes, but that's not verified. If you find/notice a (set of) use-case(s) that trigger first of these reboots after device has been powered off and back on, it would be appreciated. (I assume for now these to be separate from the main issue in this bug which was apparently triggered completely random) (In reply to comment #384) > I did have Crach reporter installed before. A few reports have gone through in > the last 24 hours. When filing bugs about crashes and you've uploaded crashes with Crash reporter, please tell in the bug about the crashing use-case the last four hexadecimals of your WLAN MAC, it can be used to identify the crashes (they're included to the crash report filename), or add to the upload a comment which helps in finding the report (and mention what that is, it could be your name, MB#<bugnumber> etc).
1.1 update fixed 32wd_to for me. 9 days and no reboots. Unsubscribing.
I am jealous Damian. (In reply to comment #385) > (In reply to comment #380) > > Created an attachment (id=2071) [details] [details] [details] > > mtd2 dump 20100121 > > > > This is my recent mtd2 dump. About 6+ reboots in the last 12 hours. Some > > 32wd_to and others sw_rst. > > There are many oopses and nowadays kernel normally does sw_rst after oops, but > it's still possible that the 32wd_to ones could be caused by the these oopses > too. This can happen if there was a bit too much time from the last HW watchdog > kicking time before that (AFAIK kicking is currently done at 12 sec intervals > with 2 secs margin before device gets rebooted by HW watchdog) and things > leading to oops or oops itself prevented user-space HW kicker from working for > while. > Lost me on the watchdog info there sorry. Can I read something simple enough to get the gist of this? > Note that in 51.1 kernel appends to the oops information the product release > information so that it's now easy to see from which release kernel they come. > > > New oopses (which were not in your previous oopslog) are from: > - BUG at unmap_vmas/release_console_sem -> internal kernel memory corruption? Hmm I know you mentioned this last time. I have run dosfsck on the /home/user/MyDocs partition several times before and after the re-flashing of the rootfs but it never seemed to find any errors. So after 2 reboots while reinstalling my packages, I moved everything off /home/user/MyDocs, formatted [mkdosfs -F 32 /dev/mmcblk0p1], remounted and copied back over. So far no reboots. It has been 24-36 hours. > - __mutex_lock_slowpath (called from twl4030_i2c_read) What is the twl4030_i2c_read? Is it some sort of hardware monitoring chip? That was it sounds like, but I am just guessing. > - cpu_v7_switch_mm > Hmmm I can't even guess here haha. > > > Often they would come in a bunch, like 2-3 random reboots in a row and then a > > few others later another 2-3 reboots. > > There have been some indications (comments in SGX HW recovery resets bug) that > a reboot might not reset the device state fully, at least sometimes, but that's > not verified. > Is there a way to? Thanks > If you find/notice a (set of) use-case(s) that trigger first of these reboots > after device has been powered off and back on, it would be appreciated. (I > assume for now these to be separate from the main issue in this bug which was > apparently triggered completely random) > Yeah I wish I could. There doesn't seem to be any pattern I am noticing. They really are random. The initial reboots only common pattern is I have at least 4 applications open. I was concious of the FS corruption but have not noticed that anything was hitting the FS hard when these happen. The subsequent reboots in the bunches happen quite quickly, so only 1 app open or so. I'll continue to try to notice a pattern. > (In reply to comment #384) > > I did have Crach reporter installed before. A few reports have gone through in > > the last 24 hours. > > When filing bugs about crashes and you've uploaded crashes with Crash reporter, > please tell in the bug about the crashing use-case the last four hexadecimals > of your WLAN MAC, it can be used to identify the crashes (they're included to > the crash report filename), or add to the upload a comment which helps in > finding the report (and mention what that is, it could be your name, > MB#<bugnumber> etc). > Every crash report gone through I have had on the first line: From: DaveQB And then followed by a brief description of what I was doing. The last report would not go through as it claimed I was trying to overwrite an existing report and I am not allowed to. I know this is perhaps forking off into another potential bug/issue, how would you like the ensuing communication to be had Eero? Forum, email, another bug etc? Thanks a lot for your time and patience.
Several people (Damien, Rash, Nicolas) have commented that the issue was fixed for them in 51.1, but David is still getting reboots. Tomasz is also getting reboots, but I'd like to hear whether reflashing 51.1 (instead of doing OTA update) gets rid of them before drawing conclusions. Could everybody who's subscribed here because you got frequent 32wd_to reboots state (if you haven't yet) whether 51.1 release fixed the issue for you or not? If there are at max only couple persons who still get them, I think this bug could be verified (and those people who still get them could consider getting a replacement device). If there are more people who still get them, I think this bug should be re-opened.
(In reply to comment #388) > Could everybody who's subscribed here because you got frequent 32wd_to reboots > state (if you haven't yet) whether 51.1 release fixed the issue for you or not? Bug is fixed for me. Had reboots every few minutes before. Even with power mode workaround I had one or two 32wd_to crashes per day. Since 51.1 I didn't have a single reboot. PS: Updated new firmware by re-flashing (wanted to make sure that I get a clean system ;-)
(In reply to comment #388) > Could everybody who's subscribed here because you got frequent 32wd_to reboots > state (if you haven't yet) whether 51.1 release fixed the issue for you or not? > It did help and I have actually tested/used my device in regular use pretty hard after the upgrade. I haven't seen any random 32_wd_to rebooting issues anymore. The device has been up and running over three days without any reboots. I think that's good enough. I also made test enabling Smartreflex with same result. Up and running also around over five days. The reason why I don't have uptime something like ten days, is only caused by me pressing the power key or using reboot command. I really believe that's possible :)
Good, so far only two people with issues and much more people whom the device works fine with 51.1. (In reply to comment #390) > The reason why I don't have uptime something like ten days, is only caused > by me pressing the power key or using reboot command. I really believe that's > possible :) I had only one device which had reboots (rebooted about after 1/2h of use). Currently it has 25 day uptime with light usage (and it would be week longer if I hadn't rebooted it manually :-)).
Mine rebooted few times an hour before I applied workaround. It's pretty solid after upgrade to 51.1 firmware (and turning off workaround). I think I had one reboot since, but this is rare enough that I don't think it is either connected or a problem.
no such reboots since pr1.1 here
51.1 fixed the problem for me.
(In reply to comment #388) > Several people (Damien, Rash, Nicolas) have commented that the issue was fixed > for them in 51.1, but David is still getting reboots. Tomasz is also getting > reboots, but I'd like to hear whether reflashing 51.1 (instead of doing OTA > update) gets rid of them before drawing conclusions. [cut] > If there are at max only couple persons who still get them, I think this bug > could be verified (and those people who still get them could consider getting a > replacement device). After flashing device reboots went away, and then started again after three days. I have send my phone to the service and will see what they will tell.
Had been crashing with wd32_to 3+ times/day before the update. Up for 7+ days since update, no crashes.
(In reply to comment #388) > Could everybody who's subscribed here because you got frequent 32wd_to reboots > state (if you haven't yet) whether 51.1 release fixed the issue for you or not? I did an OTA update to PR1.1 (actually had to do an apt-get dist-upgrade due to running out of space), and this has fixed the issue for me.
Fter 51.1, no more reboots.
After OTA update to 51.1, I still had wd32_to reboots about 1 time per day, when I was at the office (don't ask me why ;) Two days ago, I reflashed to 51.1 and reflashed eMMC too and I didn't had any reboot since.
(In reply to comment #399) > After OTA update to 51.1, I still had wd32_to reboots about 1 time per day, > when I was at the office (don't ask me why ;) Could you attach gzipped /dev/mtd2 file to here? I'm suspecting this could be an oops related to your network environment (there was one found from the oopslogs attached earlier). > Two days ago, I reflashed to 51.1 Flashing doesn't clear the mtd2 oops partition, so it's still useful. > and reflashed eMMC too and I didn't had any reboot since. Even at the office? Had you restored the network settings? Nothing changed in the office WLAN environment?
Created an attachment (id=2140) [details] mtd2 file here is mtd2 file but I think it got empty by a previous crash. However, I had crash report installed so you might have the trace handy at Nokia. my wlan mac is 00:BD:3A:88:39:43 Nothing changed in our wireless configuration at the office. And yes, I restored network settings and so far, I haven't got any reboot.
after updatei GOT the 32wd_to, Fashed device twice, firmware and emmc. Was alright for two days.Now say one reboot a day. Mostly by using fm-radio and attached to the carloader.
(In reply to comment #401) > Created an attachment (id=2140) [details] [details] > mtd2 file > > here is mtd2 file but I think it got empty by a previous crash. Crashes don't empty the oops partition either (if it gets full, old logs are just overwritten). > However, I had crash report installed so you might have the trace handy at > Nokia. my wlan mac is 00:BD:3A:88:39:43 Thanks, There were couple reboots from last years release, but no oopses. The (jpeg decompression) issue with the couple of mafw-dbus wrapper crashes you had is fixed in 51.1. So your device freeze & 32wd_to reboots were due to some other reason. Let us know if that start appearing again (more than once and if there's some other / additional pattern than just that they happen only at the office). (In reply to comment #402) > after updatei GOT the 32wd_to, Fashed device twice, firmware and emmc. Was > alright for two days.Now say one reboot a day. Mostly by using fm-radio and > attached to the carloader. Can you also check or provide the /dev/mtd2 contents?
I had this problem before upgrading to 51-1, and used the workaround of disabling off mode via /etc/pmconfig. After upgrading to 51-1, I removed the workaround from /etc/pmconfig, re-enabling off mode, and I have not experienced any further reboots.
I spoke too soon, I just got the 32wd_to crash at the office. However, crash report isn't able to upload the crash file : "file reboot-32wd_to-3943-0-0.rcore.lzo already exist and you cannot update files on this server. Try again". I got this error message several times last week, it might explain why you didn't saw any 32wd_to crash from my device.
(In reply to comment #405) > I spoke too soon, I just got the 32wd_to crash at the office. > > However, crash report isn't able to upload the crash file : "file > reboot-32wd_to-3943-0-0.rcore.lzo already exist and you cannot update files on > this server. Try again". I got this error message several times last week, it > might explain why you didn't saw any 32wd_to crash from my device. > I am getting the same issue when submitting a crash report. I don't know how to flush this report as maybe it was sent without me knowing, hence the double up, but keeps wanting to be sent again.
(In reply to comment #406) > (In reply to comment #405) > > I spoke too soon, I just got the 32wd_to crash at the office. > > > > However, crash report isn't able to upload the crash file : "file > > reboot-32wd_to-3943-0-0.rcore.lzo already exist and you cannot update files on > > this server. Try again". I got this error message several times last week, it > > might explain why you didn't saw any 32wd_to crash from my device. > > > > > I am getting the same issue when submitting a crash report. I don't know how to > flush this report as maybe it was sent without me knowing, hence the double up, > but keeps wanting to be sent again. > I deleted the report next time I rebooted and it want to send again as I know it will fail. I then had another random 32wd_to reboot and another report generated. But strangely, this was named the same [0614] and failed to send. Here is the screenshot: http://www.dward.name/pics/FailedToSend.png
(In reply to comment #406) >> I spoke too soon, I just got the 32wd_to crash at the office. >> >> However, crash report isn't able to upload the crash file : "file >> reboot-32wd_to-3943-0-0.rcore.lzo already exist and you cannot update This means that the upload server already got a HW watchdog reboot notification file with this name. >> files on this server. Try again". AFAIK the upload directory content is forwarded/emptied few times per hour and then a rich core with the same name can be uploaded again (reboot notification uploads are not expected from the same machine within few minutes...). > I am getting the same issue when submitting a crash report. I don't know > how to flush this report as maybe it was sent without me knowing, hence > the double up, but keeps wanting to be sent again. It should be enough to wait for a while (few tens of minutes?). But for the HW reboots the cores (can) contain only information about there being a reboot and from which device (identified by MAC) it came from, and the user's note in what kind of a situation it happened. The reboot uploads are mainly useful to let us know about whether they happen at all in certain release and do they seem to happen only for specific devices. If there's no bug with reproducible use-case for the reboot, there's not really much we can do for them. So... If you've already uploaded a few HW reboot notification cores, you can skip the rest of them for that _particular_ release. This upload thing shouldn't be a problem for application crash core dumps though, their file names contain also crash signal and crashed process PID i.e. one cannot get same file names until PID numbers wrap around and same process manages to get again same PID number, which in practice is impossible. For application crash and oops core files it's important to get most of them because from those cores we may actually be able to find out the reason for the crash/oops (or at least some hints how to reproduce them).
ok, (I still can't push the latest reboot core using crash report). What do you need then ? mtd2 content ?
(In reply to comment #409) > ok, (I still can't push the latest reboot core using crash report). > > What do you need then ? mtd2 content ? Yes, please (/dev/mtd2 content or the sp-oops-extract output for it).
sp-oops-extract /dev/mtd2 as root returns "no logs present". Could it be because the crash was "handled" by crash reporter ?
(In reply to comment #402) > after updatei GOT the 32wd_to, Fashed device twice, firmware and emmc. Was > alright for two days.Now say one reboot a day. Mostly by using fm-radio and > attached to the carloader. can't open /dev/mtd2 permission deneid. although i'm loged in as root. to be honnest i'm a total noob. so if there is somewere a tutorial about howto. That would be great. I also installed crashreporter, but cant 'find'it anywere. sorry if i'm poluting this topic Btw only had 1 reboot last week. is this 'tolerateble"? (is that a word?)
(In reply to comment #412) > can't open /dev/mtd2 permission deneid. That's normal. > I also installed crashreporter, but cant 'find'it anywere. It should come up automatically when needed. It should be listed in the Device Settings.
Created an attachment (id=2179) [details] Output from sp-oops-extract post wd32_to bootreason I have been experiencing several reboots with both wd32_to and sw_rst as bootreason. I have re-flashed the device eMMC and firmware but I still get random reboots. Crash Report is installed and I will upload core dumps as they occur. Please tell me if there is any other info you need from me.
(In reply to comment #411) > sp-oops-extract /dev/mtd2 as root returns "no logs present". Could it be > because the crash was "handled" by crash reporter ? No, it means that there were no oopses logged i.e. wd32_to reboots were due to a mystery device freeze (potentially one this bug is about). (In reply to comment #412) > can't open /dev/mtd2 permission deneid. although i'm loged in as root. How do you log in as root? Root should be able to read that file. > I also installed crashreporter, but cant 'find'it anywere. It's a background service started at boot. You can see it from the Application manager installed apps list and it also add an entry to the Settings application. (In reply to comment #414) > Created an attachment (id=2179) [details] [details] > Output from sp-oops-extract post wd32_to bootreason There are many interesting looking oopses from 51.1 (they repeat). Last are several network related ones NULL pointers: [31814.040954] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... [ 6963.405395] [<c02839c4>] (cond_resched_softirq+0x0/0x70) from [<c020d374>] (release_sock+0x84/0xec) [ 6963.405456] r5:c8f40480 r4:00000000 [ 6963.405517] [<c020d2f0>] (release_sock+0x0/0xec) from [<c024084c>] (tcp_recvmsg+0x728/0x84c) [ 6963.405578] r7:00000000 r6:00000544 r5:00000000 r4:c8f40480 Before that between "Log Entry 146" and "Log Entry 161" were crashes that looked like screwed up file system (at least Ext3 i.e. eMMC home one). Before that there were couple of network related oopses. Ext3 is journaled, but it's not as robust as UBIFS. If you have really bad luck and/or huge number of unclean reboots (32wd_to reboot or sw_rst caused by oops; sw_rst from SW watchdog are fine, file systems are then synched) and/or remove the battery while there's uncommited data (commit interval = 1s), it may get corrupted. > I have been experiencing several reboots with both wd32_to and sw_rst as > bootreason. I have re-flashed the device eMMC and firmware but I still get > random reboots. My guess is that the main cause is the network related oopses and if you get them often while /home is being updated, it may eventually cause the ext3 file system to get corrupted. I didn't find these network related oopses logged to our internal database, so nobody else seems to be hitting the problem you're having. This could be e.g. because it's specific to the access point you're using or something else that is specific to your use-case. Please file a separate bug about it where you put details about in which kind of situations you get the reboots, what's your network environment (access point model) etc + put me on CC.
Removing myself from CC list
I'm open bug #8787 for the 32wd_to reboot with 2.2009-51.1 firmware and "specific" WLAN environment.
I had problems with reboots with reason 32wd_to. After service has put new motherboard in my phone I had only three reboots - all of them after battery was depleted. They were the same - after connecting charger and turning on the device startup took slightly longer than usually and animation (Nokia logo, sound, connecting hands) was not displayed. Then crash reporter started telling that it has report about 32wd_to reboot. Situation does not occur when I turn off the phone using power button, nor after reboot. Besides that device acts almost normally (FM transmitter is not working). I have uploaded one reboot report, but two more are sitting in my device - I have the same problem as in comments #405 and #406. I have battery-eye installed - if it can do something with the problem. I am not opening new bug - as service managed to disable the FM radio, they might do something else that might cause this strange behaviour. Currently am trying to communicate with Nokia Care about this issue - but I am posting also here in case someone manages to have similar issue. Also I would like to be able to either send those stored crash reports and remove them from the device.