Comment 1 Ryan Abel 2010-01-16 23:21:08 UTC

Does toggling the unlock slider once or twice have any effect?

No.

I have tried a lot of things during the one hour waiting to get the device out
of this state. I have attempted to press all available buttons in a random
order to get out of this UI freeze.

I have done another test. If I leave the GSM module on during night the UI
freeze does not appear. Moreover if I go to offline mode and the alarm appears
within some minutes the UI is ok too. So it seems that it has something to do
with a very long sleep phase of the phone. I think that a lot of software
components are switched of including the X server (aka graphics card). And the
alarm application seems to grab the X server. There seems to be a race
condition between the waking up of the graphics subsystem and the grabbing of
the X server or something like that. But I do not know the architecture of the
whole maemo platform.

Comment 3 Andre Klapper 2010-01-18 16:21:19 UTC

I'd love to see a second confirmation for this.
I tried this with Offline Mode in internal version 2010.03-1 and cannot
reproduce - the Desktop works after stopping the alarm, but that was for an
alarm 3 minutes after creating it.

Ok. I will try to reproduce the bug this night. I set up an alarm for tomorrow
in the morning and switch the phone to offline mode this evening. I will report
my results tomorrow. If I trigger the event some minutes later and go to
offline mode the alarm UI works also correctly on my phone.

Please remember: I have closed all applications which show up on the dashboard
otherwise. Because if you have applications open and running there is always
activity in the system and therefore the effect does not appear (that's my
personal view of course).

Here's your second confirmation, Andre. I have been using my new N900 since
mid. december 2009 without any problems until 2 weeks ago where, at some point,
I had the first occurence of this critical problem/bug. So is this related to
some Maemo update I've accepted ? I don't know, but I know I've been updating
my OS every time there was an update available.

ACTUAL OUTCOME : 
I set a calendar event with an alarm (I've tried the "0 min, 5 min. and 30 min)
options. If the device is sleeping when the alarm fires, the whole interface
stops responding visually, but the haptic feedback system continues to "know
that I'm pushing here and there on the screen". But none of the "repeat",
"details" or "stop" button would work. I'm stuck on the "alarm" page until I
remove the battery ! 

However, the device is not frozen completely... I can use the side lock button
to put it back to sleep. After that, I can push the top button to unlock the
device (and the ball-sliding unlock operation works as expected!). As stated
earlier in first comment, if I slide open the camera cover, I can see in the
background (behind the persistent "alarm" dialog) that the camera is
initializing, but I don't see any live image from the camera... it's just
black.
I can also push the volume up and down buttons and the visuals showing my
current volume kick in as expected (but I don't know if the volume is actually
properly setup because I don't have any music playing in this state).

in this "stuck alarm" state, hitting any keyboard key doesn't seem to have any
effect of any kind.

EXPECTED OUTCOME:
same as explained in bug description.

REPRODUCIBILITY:
it's not trivial. After removing the battery and powering up, it seems that I
can fire some event alarms without any problem.... but at some point, the bug
happens. I'll try to investigate a little bit more today to get a nice "STEPS
TO REPRODUCE" with actual version of my OS and stuff.

The effect still occurs. But the good news is that I have found out the reason
for this misbehaviour. And even better, there exists a short way to easy
reproduce the error. Do the following:

1. Go to Settings -> Internet connections: Select for "automatically connect"
the value "always ask" (I translated this from the german version!)
2. Switch the phone to offline mode.
3. Set an alarm which is 3 minutes later (or whatever time you like)
4. Start the browser and enter any web address
5. A modal popup window appears: It asks you if the offline mode should be
deactivated. DO NOT PRESS ANY BUTTON!
6. Wait until the alarm arrives
7. And voila, the UI is frozen

Analysis:
The problem here is that you get 2 modal popup windows. The "offline mode" one
has grabbed the focus/keyboard/mouse because it is the first one which
appeared. The second one (alarm notification) overlays the first one but the
second one can not get the mouse input because it is already reserved by the
first one.

One solution is to inherit the focus/input to the last appeared modal window by
the UI subsystem. Of course you can also queue these events and have a separate
subsystem for such interactions.

Hope this helps to solve the problem.

Another confirmation.

First occurred on 2009-01-18. I see all the symptoms the other two posters have
reported. When it first occurred I solved the lock-up by removing the battery.
This morning I think it was cleared after switching to phone mode and then
ensuring every app was closed.

OS version is as stated 2-2009.51-1.203-2

I have forgotton another bad symptom of the "offline mode" popup window.

It drains a lot of power out of the battery if it happens in the night. I
started my attempt with an almost full battery. And 8 hours later the battery
is almost completely empty :(. But I thought that going into offline mode
during the night is good because it is the best way to save power. But the
reality is a little bit different.
I have forgotton another bad symptom of the "offline mode" popup window.

It drains a lot of power out of the battery if it happens in the night. I
started my attempt with an almost full battery. And 8 hours later the battery
is almost completely empty :(. But I thought that going into offline mode
during the night is good because it is the best way to save power. But the
reality is a little bit different.

Comment 9 Andre Klapper 2010-01-19 14:24:44 UTC

*** Bug 8244 has been marked as a duplicate of this bug. ***

Comment 10 Andre Klapper 2010-01-19 14:58:07 UTC

(In reply to comment #6)
> There exists a short way to easy reproduce the error.

Awesome. Thanks so much for the investigations here, I can reproduce it too.

Comment 11 Andre Klapper 2010-01-19 15:11:28 UTC

Do you have the RSS feed reader widget on your desktop?
Bug 8002 might be the root of this problem, while comment 6 is a great way to
see its outcome.

confirmed. I have the RSS feed reader on my desktop.

Yes. I have also the RSS feed reader on my desktop.

(In reply to comment #13)
> Yes. I have also the RSS feed reader on my desktop.
> 

So the best way at the moment is to deactivate the automatic update of the RSS
feed widget - it is not working as expected....

(In reply to comment #14)
> (In reply to comment #13)
> > Yes. I have also the RSS feed reader on my desktop.
> > 
> 
> So the best way at the moment is to deactivate the automatic update of the RSS
> feed widget - it is not working as expected....
> 

This will avoid the described problem...

Confirmed.  
robiwan's solution of deactivating the RSS Reader Widget on the desktop last
night worked. Alarm fired okay and I could stop it without problem. 
Thanks guys.

(In reply to comment #16)
> Confirmed.  
> robiwan's solution of deactivating the RSS Reader Widget on the desktop last
> night worked. Alarm fired okay and I could stop it without problem. 
> Thanks guys.
> 

Deactivating the whole widget is NOT neccessary - it is enough to deactivate
the auto update setting....

(In reply to comment #17)
> (In reply to comment #16)
> > Confirmed.  
> > robiwan's solution of deactivating the RSS Reader Widget on the desktop last
> > night worked. Alarm fired okay and I could stop it without problem. 
> > Thanks guys.
> > 
> 
> Deactivating the whole widget is NOT neccessary - it is enough to deactivate
> the auto update setting....
> 

AND - i hope auto update will work again in the next release - because
deactivating it is only a workaround - not a fix

I can confirm this problem. Alarm sound goes on and you can hear the touchpad
clicks (when enabled) but nothing happens. My workaround is I put the phone in
portrait mode to start the phone app. This seems to push the alarm clock
away...

I've just got this problem too, and I'm quite sure that what happened is what
has been described in comment #6.

And I don't know what happened, but I didn't have to remove the battery: after
removing the battery cover, I didn't manage to do it with my fingers, but then
I noticed that I had the message saying if I want to leave offline mode, and I
could answer.

(In reply to comment #11)

> Do you have the RSS feed reader widget on your desktop?
> Bug 8002 might be the root of this problem, while comment 6 is a great way to
> see its outcome.

Yep, RSS feed reader here too. For silencing the alarm, flipping the phone face
down still works ok and after that you can get to the "offline" prompt below.

I'm not sure. I think I had this bug this morning.

I woke up, snooze the alarm. Watched on my EMails, saw a Update from maemo
extras (VNC), I installed it and in the moment the update finished and the
complete message appeared the alarm appears and the UI freezed. I was not able
to cancel it or shutdown the phone. I had to remove the battery.

I hope this has something to do with this bug and could help. But I guess, the
yellow message that appears after a installation prozess is not a modal dialog.

Comment 24 Andre Klapper 2010-02-01 14:36:31 UTC

This has been fixed in package
osso-systemui-modechange 0.3.5+0m5
which is part of the internal build version
2010.05-2
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Created an attachment (id=2323) [details]
Screenshot of Battery-Eye

Yesterday I also encountered this bug, exactly as described here. Phone in
offline mode -> alarm -> unable to tap any button. Only the lock-slider and
powerbutton-swipe responded. When i finally wanted to remove the battery, the
phone asked if i wanted to exit offline. I was also using the RSS widget.

I'm running PR 1.1.1 which apparently comes with osso-systemui-modechange
0.3.4+0m5. Why isn't the version with the bugfix included??? It was fixed
before PR1.1.1 was released... :/

This morning i had a similar issue, but now i really had to pull out the
battery:
EXACT STEPS LEADING TO PROBLEM: 
1. Set the alarm clock at 8:25
2. Activate the silent profile (so i can sleep without being called)
3. Lock the phone by pressing the powerbutton twice
4. Leave Mauku (2beta4) running, so it can update during the night (i simply
leave it open during the night instead of using the mauku-widget, which i don't
really like)
5. I also had 1 other program open, but i forgot which one
6. Leave the phone in Online mode (otherwise there would be no point in leaving
Mauku running)

EXPECTED OUTCOME:
In the morning at 8:25 i wake up by the sounds of the alarm, I tap 'Stop' and
have shower.

ACTUAL OUTCOME:
At 8:28 i wake up, because i hear my phone is buzzing. But NO alarm sound is
being played and nothing is displayed on the screen (it's entirely black). I
try to stop the buzzing, but the phone does not respond. I can't even get it to
display something on the screen. The slide-button and powerbutton did not have
any effect at all. In the end i removed the battery to stop the buzzing (which
had been going on for more than 6 minutes by then)

This may be completely unrelated, but when i had a look at Battery-Eye this
morning i noticed a rather strange graph (see attachment). I went to sleep at
0:30 and attached the phone to the charger. However the battery kept draining
instead of charging until around 4:00 in the morning until it was completely
empty and then after one hour it finally started to charge. It was only charged
30 minutes before the alarm went of...

Comment 27 Andre Klapper 2010-02-20 12:55:27 UTC

(In reply to comment #26)
> Why isn't the version with the bugfix included??? It was fixed
> before PR1.1.1 was released... :/

Please check your statements first.
Comment 24 clearly says that this was fixed in year 2010, week 05.
PR1.1.1 was packaged in year 2010, week 02 (3.2010.02-8).
Anyway, offtopic here.

This bug is fixed internally, no further comments needed.

Comment 28 Andre Klapper 2010-03-06 15:26:58 UTC

*** Bug 9419 has been marked as a duplicate of this bug. ***

Comment 29 Andre Klapper 2010-03-15 20:57:08 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).

Comment 30 Andre Klapper 2010-03-16 13:15:48 UTC

*** Bug 9570 has been marked as a duplicate of this bug. ***

Comment 31 Andre Klapper 2010-04-12 16:02:55 UTC

*** Bug 9883 has been marked as a duplicate of this bug. ***

Comment 32 Andre Klapper 2010-04-16 18:50:05 UTC

*** Bug 9941 has been marked as a duplicate of this bug. ***