Created an attachment (id=760) [details]
List of installed packages

List of packages created by running dpkg -l

Created an attachment (id=761) [details]
Coredump

From /media/mmc1/core-dumps

Comment 3 Eero Tamminen 2008-05-15 16:04:30 UTC

> STEPS TO REPRODUCE THE PROBLEM: Plug in the charger
> EXPECTED OUTCOME: Device charges.
> ACTUAL OUTCOME: Device crashes -> boots -> crashes again -> boots ...

And the reboot loop stops when you disconnect the charger?

Are you using the original N800 charger or something else?

If you have another compatible charger, does the problem
occur also with that?

Did you have about one bme core dump per each reboot?

(In reply to comment #3)
> > STEPS TO REPRODUCE THE PROBLEM: Plug in the charger
> > EXPECTED OUTCOME: Device charges.
> > ACTUAL OUTCOME: Device crashes -> boots -> crashes again -> boots ...
> 
> And the reboot loop stops when you disconnect the charger?

Yes.
> 
> Are you using the original N800 charger or something else?
> 
The original mostly. See below.

> If you have another compatible charger, does the problem
> occur also with that?
> 
I got the reboot loop once with a compatible charger. But I just recently
bought it.

> Did you have about one bme core dump per each reboot?
> 

I really can't tell. What I can tell the core-dump gets overwritten every time
crash oocurs.

Created an attachment (id=767) [details]
A new coredump

Coredump of today. Switched on a fully charged device with charger plugged in.
It rebooted after a minute or so.

Comment 6 Eero Tamminen 2008-05-16 18:51:51 UTC

> I really can't tell. What I can tell the core-dump gets overwritten every time
> crash oocurs.

Oh, yes it gets same PID etc.  It's not necessary to provide more core dumps.
(bme along with the couple of other processes started from the initfs are
really hard to debug, lets first see whether the current two cores are enough)

In the off-chance that this something to do with this, is your memory card
cover properly closed when the device boots?

Thanks!

Comment 7 Eero Tamminen 2008-05-19 16:47:13 UTC

Does the crash/reboot happen only if you boot with charger, or
if you plug the charger in when the device is already running?

(In reply to comment #6)
> > I really can't tell. What I can tell the core-dump gets overwritten every time
> > crash oocurs.
> 
> Oh, yes it gets same PID etc.  It's not necessary to provide more core dumps.
> (bme along with the couple of other processes started from the initfs are
> really hard to debug, lets first see whether the current two cores are enough)
> 
Good to know. Let me know if you need more core-files, I'll try to archive them
somewhere.

> In the off-chance that this something to do with this, is your memory card
> cover properly closed when the device boots?
> 
> Thanks!
> 

The memory card cover seems to be properly closed, but I'll keep eye on it.

(In reply to comment #7)
> Does the crash/reboot happen only if you boot with charger, or
> if you plug the charger in when the device is already running?
> 

What I can remember I've had device crashing both ways.

It seems like the race condition(?) occurs when battery is fully charged. I
once noticed it happening even when the device was "switched off".

(In reply to comment #6)
>
> In the off-chance that this something to do with this, is your memory card
> cover properly closed when the device boots?
>

It seems to be. But! The problem seems to occur atleast more frequently if not
allways if the stand is open. So it might be possible that the external
memocard slot's cover is somewhat dodgy.

Comment 10 Eero Tamminen 2008-06-24 18:20:27 UTC

There was one similar old internal bug during Diablo development, but it turned
out to be non-reproducible.  Maybe this issue is fixed in the just released
Diablo release[1], could you test it?

http://maemo.org/news/announcements/view/os2008_feature_upgrade-reflash_your_tablet-for_the_last_time.html

(My favorite new feature is much improved browser performance on zooming
of certain heavy www-pages.)

(In reply to comment #10)
> There was one similar old internal bug during Diablo development, but it turned
> out to be non-reproducible.  Maybe this issue is fixed in the just released
> Diablo release[1], could you test it?
> 

It reboots. Damn. I'll attach the core-dump created.

Created an attachment (id=797) [details]
Diablo coredump.

Comment 13 Eero Tamminen 2008-06-27 13:59:00 UTC

(In reply to comment #11)
>> Maybe this issue is fixed in the just released
>> Diablo release[1], could you test it?
> 
> It reboots. Damn. I'll attach the core-dump created.

Thanks, we'll check this better. Hopefully it gets fixed for Diablo+1
bugfix release.

Comment 14 Eero Tamminen 2008-08-18 12:15:42 UTC

Have you by any chance enabled the R&D mode with the flasher at any point?
(it doesn't get cleared when the device is re-flashed)

When this bug happens, does it look like the normal charging bootup
(charging icon), or normal bootup (bug 3555)?

I've seem to have resolved the issue by buying a new battery. I'll try again
with the latest (5.208.43-7) firmware and the old battery when I have time.

I've got this bug today. :/

My battery was fully discharged, and there was only charger from Nokia phone.
After the full charge... It boots, then gets slower and slower, and reboots at
the end after a minute (by internal watchdog timer?). But it doesn't occur
without memory card in inner slot. :/

Comment 17 Eero Tamminen 2009-02-23 10:56:26 UTC

(In reply to comment #16)
> I've got this bug today. :/
> 
> My battery was fully discharged, and there was only charger from Nokia phone.
> After the full charge... It boots, then gets slower and slower, and reboots at
> the end after a minute (by internal watchdog timer?). But it doesn't occur
> without memory card in inner slot. :/

Then sounds like a memory card handling issue, not battery one.  Most likely
you've corrupted the memory card file system[1] and some program[2] didn't like
that.  If this is the case, you need either to repair the memory card file
system or re-format it.  Before that, please check with "top" in XTerm what is
taking the CPU and report it here first.

[1] The legacy MicroSoft FAT file system is easy to corrupt (by not using
"safely remove" or taking card out while it's being written), but FAT is needed
for interoperability reasons.

[2] If you don't have the latest release, it could be metalayer crawler that's
slowing things down (see bug 1842), but it shouldn't be able to cause
reboots...


Another possibility is that something is constantly rewriting large parts of
contents on your device internal storage, but that shouldn't cause reboots
either, just slowdown (see bug 2615).

(In reply to comment #17)
> Then sounds like a memory card handling issue, not battery one.  Most likely
> you've corrupted the memory card file system[1] and some program[2] didn't like
> that.  If this is the case, you need either to repair the memory card file
> system or re-format it.  Before that, please check with "top" in XTerm what is
> taking the CPU and report it here first.

First of all, it was problem with inner slot, not card itself (found by
switching card/slots, etc.) Second, the bug is disappeared after partially
discharge of battery.
Sounds weird.

Comment 19 Eero Tamminen 2009-02-23 17:17:33 UTC

> First of all, it was problem with inner slot, not card itself (found by
> switching card/slots, etc.) Second, the bug is disappeared after partially
> discharge of battery.

Does it happen with other cards?  (Different cards request and need different
amounts of power from the slot and the slots are handled a bit differently
because they have different power regulators)

(In reply to comment #19)
> Does it happen with other cards?

I have 2 SD cards: Nokia miniSD 128MB from N800 box, and Transcend 4GB. I was
able to reproduce bug only when any of those two was in inner slot, regardless
what was (or wasn't) in outer slot.

As I said before I can't reproduce this bug now. And I don't really want to. :)

Comment 21 Andre Klapper 2009-04-23 16:59:46 UTC

There has been a fix for Diablo after the public 5.2008.43-7 release, but Nokia
hasn't pushed another Diablo update (and is unlikely to do so according to
several postings on ITt). Hence: FIXED for Diablo, but not available for public
(yet). :-/

Comment 22 Eero Tamminen 2009-04-23 17:37:38 UTC

Also, as bme is on initfs (the issue is though to be bme not ignoring SIGPIPEs
when its client dies), unfortunately there's no test package that could be
provided for testing whether the bme update actually fixes this issue. It needs
full SSU update.

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