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?

Comment 9 Andre Klapper 2009-11-26 20:28:38 UTC

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...

Comment 10 Andre Klapper 2009-11-26 20:31:59 UTC

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.

Comment 20 Eero Tamminen 2009-11-27 10:44:39 UTC

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.

Comment 25 Eero Tamminen 2009-11-27 12:05:00 UTC

(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.

Comment 28 Eero Tamminen 2009-11-27 13:13:27 UTC

(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

Comment 39 Eero Tamminen 2009-11-30 16:50:54 UTC

(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!

Comment 48 Andre Klapper 2009-12-01 11:38:08 UTC

(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.

Comment 54 Eero Tamminen 2009-12-01 20:48:16 UTC

(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.

Comment 59 Eero Tamminen 2009-12-02 17:03:21 UTC

(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

Comment 66 Eero Tamminen 2009-12-03 16:11:07 UTC

(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.

Comment 68 Eero Tamminen 2009-12-03 18:42:02 UTC

(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

Comment 72 Eero Tamminen 2009-12-04 15:45:04 UTC

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.

Comment 75 Eero Tamminen 2009-12-04 18:46:42 UTC

(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.

Comment 77 Eero Tamminen 2009-12-04 18:55:28 UTC

(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?

Comment 97 Neil MacLeod 2009-12-07 17:38:55 UTC

(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.

Comment 103 Andre Klapper 2009-12-07 23:08:48 UTC

(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.

Comment 110 Eero Tamminen 2009-12-08 15:58:55 UTC

(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?

Comment 111 Eero Tamminen 2009-12-08 16:01:22 UTC

(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?)

Comment 125 Eero Tamminen 2009-12-09 16:17:44 UTC

(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.

Comment 127 Eero Tamminen 2009-12-09 16:50:43 UTC

(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?

Comment 129 Eero Tamminen 2009-12-09 17:53:06 UTC

(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

Comment 136 Eero Tamminen 2009-12-09 20:01:38 UTC

(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.

Comment 142 Andre Klapper 2009-12-09 21:08:02 UTC

*** 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.

Comment 148 Eero Tamminen 2009-12-10 12:47:23 UTC

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.

Comment 154 Eero Tamminen 2009-12-10 14:14:18 UTC

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.

Comment 160 Andre Klapper 2009-12-10 15:01:57 UTC

(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!

Comment 162 Eero Tamminen 2009-12-10 15:26:11 UTC

(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 ?

Comment 165 Eero Tamminen 2009-12-10 17:18:24 UTC

(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

Comment 168 Andre Klapper 2009-12-10 19:16:50 UTC

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.

Comment 171 Andre Klapper 2009-12-10 19:49:17 UTC

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.

Comment 178 Eero Tamminen 2009-12-11 11:23:44 UTC

(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.

Comment 181 Andre Klapper 2009-12-11 13:11:14 UTC

(In reply to comment #180)
> My device suffers from random reboots as well.

Please see comment 20.

Comment 182 Eero Tamminen 2009-12-11 13:40:39 UTC

(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.

Comment 184 Andre Klapper 2009-12-11 15:32:30 UTC

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.

Comment 187 Eero Tamminen 2009-12-11 16:52:59 UTC

(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...?????

Comment 192 Andre Klapper 2009-12-11 22:53:31 UTC

(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.

Comment 203 Andre Klapper 2009-12-13 15:31:44 UTC

(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

Comment 213 Eero Tamminen 2009-12-14 18:33:53 UTC

(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.

Comment 226 Eero Tamminen 2009-12-15 12:39:53 UTC

(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

Comment 228 Eero Tamminen 2009-12-15 14:16:48 UTC

(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

Comment 241 Eero Tamminen 2009-12-16 11:23:07 UTC

(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.

Comment 242 Eero Tamminen 2009-12-16 11:41:18 UTC

(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.

Comment 246 Eero Tamminen 2009-12-16 13:56:55 UTC

(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.

Comment 248 Eero Tamminen 2009-12-16 14:14:20 UTC

(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

Comment 258 Andre Klapper 2009-12-18 15:04:31 UTC

(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! :)

Comment 259 Eero Tamminen 2009-12-18 15:27:55 UTC

(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.

Comment 277 Andre Klapper 2009-12-22 12:33:50 UTC

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.

Comment 279 Eero Tamminen 2009-12-23 11:39:00 UTC

(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).

Comment 299 Eero Tamminen 2009-12-28 16:26:47 UTC

> 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.

Comment 304 Eero Tamminen 2009-12-29 11:22:50 UTC

(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.

Comment 308 Andre Klapper 2009-12-29 18:37:20 UTC

(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!!)

Comment 338 Andre Klapper 2010-01-07 19:13:31 UTC

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?

Comment 352 Andre Klapper 2010-01-12 15:23:34 UTC

(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...

Comment 353 Eero Tamminen 2010-01-12 17:12:57 UTC

(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.

Comment 355 Eero Tamminen 2010-01-13 10:28:51 UTC

(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?

Comment 358 Eero Tamminen 2010-01-13 15:04:35 UTC

(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!)

Comment 365 Eero Tamminen 2010-01-14 11:29:10 UTC

(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.

Comment 370 Eero Tamminen 2010-01-15 10:07:26 UTC

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.

Comment 373 Eero Tamminen 2010-01-15 11:25:09 UTC

(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.

Comment 377 Eero Tamminen 2010-01-18 10:43:43 UTC

(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.

Comment 383 Eero Tamminen 2010-01-22 11:30:26 UTC

(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.

Comment 385 Eero Tamminen 2010-01-22 16:28:57 UTC

(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.

Comment 388 Eero Tamminen 2010-01-25 10:54:29 UTC

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 :)

Comment 391 Eero Tamminen 2010-01-25 16:04:34 UTC

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.

Comment 400 Eero Tamminen 2010-01-27 14:49:27 UTC

(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.

Comment 403 Eero Tamminen 2010-01-27 16:19:04 UTC

(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

Comment 408 Eero Tamminen 2010-02-01 10:38:33 UTC

(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 ?

Comment 410 Eero Tamminen 2010-02-01 12:10:37 UTC

(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?)

Comment 413 Andre Klapper 2010-02-01 12:29:56 UTC

(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.

Comment 415 Eero Tamminen 2010-02-01 13:35:15 UTC

(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.