maemo.org Bugzilla – Bug 6145
MfE spams screen with error messages when it cannot connect to the server
Last modified: 2010-01-14 12:26:04 UTC
You need to
before you can comment on or make changes to this bug.
Maemo 5 - 1.2009.41-10
STEPS TO REPRODUCE THE PROBLEM:
1. Configure Mail for Exchange to synchronize with a server.
2. Connect to a wireless access point that requires web-based login.
3. DO NOT log in to the wireless network.
Mail for Exchange either silently accepts a connection to the server is
impossible or provides a single error message to the user. Either way, it goes
to sleep for some reasonably long period of time before retrying.
Mail for Exchange spams the screen with connection failure messages: "Error.
Either Exchange server requires secure connection or account is disabled."
This would also suggest a connection failure leads to MfE retrying the
connection in a tight loop. Indeed, top shows a load average of around 2 with
"as-daemon" taking 32-35% of CPU and dbus-daemon taking 12-17%. This may be a
battery draining bug.
EXTRA SOFTWARE INSTALLED:
I expect other network or server problems that prevent MfE from properly
connecting to the server will also trigger this behaviour, but I haven't yet
been able to test beyond specific situation given in the steps above.
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
rv:18.104.22.168) Gecko/20091102 Firefox/3.5.5
Created an attachment (id=1581) [details]
video of error message
I'm attaching a video of the error message.
"Error: Either Exchange server requires secure connection or account is
What kind of Exchange server is this (5.5, 2003, 2007,...)?
(In reply to comment #2)
> What kind of Exchange server is this (5.5, 2003, 2007,...)?
In this case, the server is m.google.com, whatever that's running. However, I'm
not sure it matters. This bugs appears when a network problem prevents MfE from
connecting to the Exchange server.
This sounds like int-142747 which has been closed as it could not be reproduced
in version 42-5 (and as a similar bug had been closed in that week).
Would be great to know if this still happens with the final version that should
be out soon. --> moreinfo
(In reply to comment #4)
> Would be great to know if this still happens with the final version that should
> be out soon. --> moreinfo
Once I have PR1.0 firmware, I'll test this again and update or close the bug.
*** Bug 6163 has been marked as a duplicate of this bug. ***
Created an attachment (id=1593) [details]
screenshot of top showing as-daemon and the repeated display of the error
message is sucking CPU
(In reply to comment #4)
> This sounds like int-142747 which has been closed as it could not be reproduced
> in version 42-5 (and as a similar bug had been closed in that week).
> Would be great to know if this still happens with the final version...
I've upgraded to 1.2009.42-11.002 and re-imaged the eMMC. After repeating the
steps in this bug, I'm seeing the same rapidly repeating error message as
I'm attaching a screenshot of top running as the bug is occurring. I'd closed
all other applications prior to this, so X Terminal is the only (user)
application running. In the screenshot, top is showing the load average as
"2.87 2.53 2.25". It spikes to 3.21 or higher, and I feel this bug could have a
bad effect on the battery life of N900s that attempt to sync during times of
network or server trouble.
Thanks a lot for retesting! Reopened internally.
Okay, clarification: This was fixed in 2.2009.42-5 which is another branch than
the one 1.2009.42-11 is based on (hence the "2" instead of the "1" in front).
So the fix is NOT included in 1.2009.42-11 and will be included in the first
(In reply to comment #9)
> Okay, clarification: This was fixed in 2.2009.42-5 which is another branch than
> the one 1.2009.42-11 is based on (hence the "2" instead of the "1" in front).
> So the fix is NOT included in 1.2009.42-11 and will be included in the first
when is the next update expected? I need Mfe to work soon (phone is useless
Nokia has never announced release dates in advance and I don't think they will
I have verified that this is fixed in 2.2009.51-1.
The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update