Just to make it clear: the SD card is brand new too.

Comment 2 Andre Klapper 2010-01-19 16:11:22 UTC

So this is missing some steps...
For example I assume that you have inserted the microSD card at some point. ;-)
"or something" isn't really helpful either.

How did you verify that the SD card was OK before inserting it in the N900?
How exactly did you got told that it was corrupted?

If you dosfsck the card from desktop using a card reader, does that think that
the card is also corrupted?

Also, 44-1 is not the last software version, but 2.2009.51-1.

Sorry for the lack of clarity. The SD card has been inserted in the slot before
turning the device on for the first time.

The exact message (yellow band at the top of the screen) is: "memory card
corrupted".

As to knowing that the card was working properly, I transfered files to and
from it some days before (USB connection to the device in "mass storage" mode),
and was able to read the files back on the device.

As for dosfsck, I'll check when I get back home. I'm not sure I have a reader
that supports microSD cards.

Also, I'm aware that there is a Meamo update pending. Will install it over the
weekend and see if this helps.


All of this being said:
- the card filesystem is (hopefully) not actually corrupt. After doing a power
cycle of the device, the card could be accessed again, and all its contents was
still there.
- I just had the same situation today (message "memory card corrupted" --
twice) -- didn't do anything on the phone at the time, I just unlocked the
display to check the reception bars. But now, a few hours later but no power
cycle since, I can once again access the card contents.

So it looks more like the media is unmounted for some reason, then
automatically re-mounted (at least some of the times). Next time it occurs,
I'll check to see if I can learn more from the command prompt.

I'll also post an update once I'll have updated to 2.2009.51-1.

The problem occurred a few more times, so I've investigated the issue from the
command line. What happens is that the device vanishes from the mount list from
time to time (why, I have no idea, of course). And then, it re-appears later on
(through udev auto-mounting, I suppose).

The mount line looks like this:
/dev/mmcblk1p1 on /media/mmc1 type vfat...

So the problem does not, in fact, stem from a real corruption (I'm glad about
that). I suppose it could be a hardware problem (flaky connector) or a udev
instability.

Updated to 2.2009.51-1 yesterday. I can confirm that the problem still occurs:
the SD card has just vanished from the mount list once again this morning.

Changed bug title to more accurately describe the symptoms, updated the version
field to reflect the upgrade of the device.

I've had a similar experience. The microSD card suddenly disappears, and will
only reappear if I either reboot or just remove it and return it.

I've connected it to my desktop computer via a card-reader and FSCK-ed it, and
there's nothing wrong with. All the data on it is intact.

From the N900 xterm I can see that the device is simply umounted and I can't
find anything relevant in dmesg.

My N900 is updated to 2.2009.51-1.003, the SD card is a 16Gb Kingston card.

Comment 7 Eero Tamminen 2010-02-04 16:55:30 UTC

There's no fsck done on the device when the card is mounted (discussed in
another bug, would use too much RAM and take too long for large full file
system, especially when user is frequently using mass storage mode over USB).

Kernel will re-mount the disk as RO if it notices problems when it's being
accessed.  Don't know what could cause it just to disappear, but I would assume
kernel to tell about it.

When this problem appears next, could you do "dmesg > dmesg.txt" in XTerm and
atttach here the dmesg.txt file?

OK, will get dmesg output next time it happens and post it here.

This being said, if the device were remounted R/O, I would still expect to find
it listed by mount, albeit with the "ro" option. That's not the case. The
"/media/mmc" entry is just gone.

Comment 9 Eero Tamminen 2010-02-04 17:15:25 UTC

I'm wondering whether the mount part of re-mount could be going wrong...

I had another look at the dmesg output, and I think that there are two separate
issues here.

It seems that the sensor that detects if the back cover is open or closed is
too sensitive. I am NOT opening and closing the back cover all the time,
however, I can find the following in dmesg:

[13910.024688] mmc0: cover is open, card is now inaccessible
[13910.163757] mmc0: cover is closed, card is now accessible
[13910.789062] mmc0: cover is open, card is now inaccessible
[13910.858489] mmc0: cover is closed, card is now accessible

The interesting thing is that sometimes it appears that even though the dmesg
says that the card is no accessible, it doesn't show that the MMC card is
available. 

In other cases, when the SD card is available, the dmesg output looks like
this:

[13034.390228] mmc0: cover is open, card is now inaccessible
[13034.698913] mmc0: card a7a5 removed
[13034.891876] mmc0: cover is closed, card is now accessible
[13035.105590] mmc0: host does not support reading read-only switch. assuming
write-enable.
[13035.105651] mmc0: new high speed SDHC card at address a7a5
[13035.156982] mmcblk0: mmc0:a7a5 SD16G 14.9 GiB 
[13035.157287]  mmcblk0: p1

The first issue is that the cover sensor is tripped even when the cover wasn't
opened and closed. The second is that sometimes when the cover is marked as
"closed", the card is not remounted.

Also, when this happened the last time, I tried opening and closing the
back-cover, and that fixed the problem - no need to reboot or to remove the SD
card and put it back in again.

In reply to comment #10:
Very interesting -- most of the times I noticed the event, it was when I was
pulling the device from its carrying case.

Since upgrading to 2.2009.51-1, I only had the problem twice -- but maybe the
improvement has nothing to do with the update, then.

This being said, I noticed the same messages in dmesg the other day (cover
open/close events), without this triggering a "memory card corrupted" error.

(In reply to comment #11)
> This being said, I noticed the same messages in dmesg the other day (cover
> open/close events), without this triggering a "memory card corrupted" error.

Maybe the "memory card corrupted" issue is caused by the problem mentioned in
comment #7.

The flow would be: 
1. The cover sensor is tripped
2. The hardware makes the SD card unavailable, forcibly unmounting it, causing
corruption.
3. The hardware immediately makes the SD card available again, but because
there is no FSCK done on mount, you get a nice "Memory Card Corrupted" message
instead of a mounted SD card.

(In reply to comment #12)
[...]
> 2. The hardware makes the SD card unavailable, forcibly unmounting it, causing
> corruption.
Could be. But wouldn't it be logical to expect the kernel to perform a clean
unmount when receiving the cover open event ? After all, the whole point is to
allow the user to remove and put back the SD card without having to shutdown
the phone.

Also, if the FS was indeed flagged "not clean", how come the FS is sometimes
remounted later on without any manual intervention ?

I'm perplexed.

This being said, the event happened again something like 30 min. ago, and I
captured the dmesg and mount output this time. Here are the relevant lines from
dmesg:

-------------------------<cut>------------------------
[19152.432861] mmc0: cover is closed, card is now accessible
[19152.687927] mmc0: cover is open, card is now inaccessible
[19152.856903] mmc0: cover is closed, card is now accessible
[19153.161254] mmc0: cover is open, card is now inaccessible
[19153.271911] mmc0: error -19 whilst initialising SD card
[...]
[19289.840057] mmc0: cover is closed, card is now accessible
[19289.849975] slide (GPIO 71) is now closed
[19290.357757] mmc0: host does not support reading read-only switch. assuming
write-enable.
[19290.357818] mmc0: new high speed SDHC card at address 8fe4
[19290.402770] mmcblk0: mmc0:8fe4 SU16G 14.8 GiB 
[19290.403228]  mmcblk0: p1
[19295.178405] kb_lock (GPIO 113) is now closed
[19295.459320] kb_lock (GPIO 113) is now open
-------------------------<cut>------------------------

Notice the "mmc0: error -19 whilst initialising SD card".

Also, here is how the mount list looked at the same time:

-------------------------<cut>------------------------
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,bulk_read,no_chk_data_crc)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,noatime,size=1024k)
tmpfs on /var/run type tmpfs (rw,nosuid,noatime,size=256k,mode=755)
none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noatime,size=65536k)
/dev/mmcblk0p2 on /home type ext3
(rw,noatime,errors=continue,commit=1,data=writeback)
nodev on /sys/kernel/debug type debugfs (0)
/opt/pymaemo/usr/lib/python2.5 on /usr/lib/python2.5 type bind (bind)
/opt/pymaemo/usr/share/pyshared on /usr/share/pyshared type bind (bind)
/opt/pymaemo/usr/lib/pyshared on /usr/lib/pyshared type bind (bind)
/opt/pymaemo/usr/share/python-support on /usr/share/python-support type bind
(bind)
/opt/pymaemo/usr/lib/python-support on /usr/lib/python-support type bind (bind)
/dev/mmcblk0p1 on /home/user/MyDocs type vfat
(rw,noauto,nodev,noexec,nosuid,noatime,nodiratime,utf8,uid=29999,shortname=mixed,dmask=000,fmask=0133,rodir)
-------------------------<cut>------------------------

As you can see, no entry for "/dev/mmcblk1p1 on /media/mmc1".

Comment 15 Eero Tamminen 2010-02-08 17:15:35 UTC

(In reply to comment #10)
> I had another look at the dmesg output, and I think that there are two
> separate issues here.
> 
> It seems that the sensor that detects if the back cover is open or closed is
> too sensitive. I am NOT opening and closing the back cover all the time,
> however, I can find the following in dmesg:

(In reply to comment #11)
> In reply to comment #10:
> Very interesting -- most of the times I noticed the event, it was when
> I was pulling the device from its carrying case.

The back cover has a magnet switch to detect the cover opening.

Do you use a case for the device which is closed with a (strong) magnet instead
of velcro fastener?  Or is it e.g. close to a belt buckle that's strongly
magnetic?


> Since upgrading to 2.2009.51-1, I only had the problem twice -- but maybe the
> improvement has nothing to do with the update, then.

AFAIK the back cover opening code in latest release has improvements to the
memory card unmounting on back cover open.


(In reply to comment #13)
>> 2. The hardware makes the SD card unavailable, forcibly unmounting it,
>> causing corruption.
>
> Could be. But wouldn't it be logical to expect the kernel to perform
> a clean unmount when receiving the cover open event?

It tries to, but user-space could be preventing it e.g. by writing to it
constantly (which could happen e.g. with video streaming in Flashplayer ads or
Youtube).


> After all, the whole point is to allow the user to remove and put back
> the SD card without having to shutdown the phone.

No. As far as I know the back cover detection is there to cut the power to the
memory cards to prevent them being (physically) damaged.  This is mainly for
the eMMC and battery being disconnected.

Kernel tries to do an unmount to prevent also memory card file system
corruption, but there are many things that can prevent the unmounting.

Please avoid opening the back cover and/or taking the battery out while device
is powered on.


> Also, if the FS was indeed flagged "not clean", how come the FS is sometimes
> remounted later on without any manual intervention ?

AFAIK there's no such flag.  Do you have something that could fool the magnetic
switch?

(In reply to comment #15)
> The back cover has a magnet switch to detect the cover opening.
> 
> Do you use a case for the device which is closed with a (strong) magnet instead
> of velcro fastener?  Or is it e.g. close to a belt buckle that's strongly
> magnetic?
Well done, Eero! You hit the jackpot. Yes, since the N900 didn't come with a
carrying case of its own, I bought a very nice black leather Hama case... that
snaps close using its magnetic lid. Bummer! Will have to find another one.

> Please avoid opening the back cover and/or taking the battery out while
> device is powered on.
Sure.

Comment 17 Eero Tamminen 2010-02-08 18:15:32 UTC

(In reply to comment #16)
>> The back cover has a magnet switch to detect the cover opening.
>> 
>> Do you use a case for the device which is closed with a (strong) magnet
>> instead of velcro fastener?  Or is it e.g. close to a belt buckle that's
>> strongly magnetic?

> Yes, since the N900 didn't come with a carrying case of its own, I bought
> a very nice black leather Hama case... that snaps close using its magnetic
> lid. Bummer! Will have to find another one.

Before doing this, could you verify that putting the device into your case
and/or taking it out from there really is causing these dmesg messages to
happen? (while not having any apps open to prevent the possible file system
corruption and afterward doing fsck from a PC just in case...)

Quim, if this was the issue, I think it needs to be documented somewhere on
Maemo pages...


Btw. Discussion about device fsck is bug 5767 comment 10 forward.  Issue with
notifications about corruption is bug 5997.

(In reply to comment #15)
> (In reply to comment #10)
> > I had another look at the dmesg output, and I think that there are two
> > separate issues here.
> > 
> > It seems that the sensor that detects if the back cover is open or closed is
> > too sensitive. I am NOT opening and closing the back cover all the time,
> > however, I can find the following in dmesg:
> 
> (In reply to comment #11)
> > In reply to comment #10:
> > Very interesting -- most of the times I noticed the event, it was when
> > I was pulling the device from its carrying case.
> 
> The back cover has a magnet switch to detect the cover opening.
> 
> Do you use a case for the device which is closed with a (strong) magnet instead
> of velcro fastener?  Or is it e.g. close to a belt buckle that's strongly
> magnetic?
> 

Jackpot for me as well. My carrying pouch does indeed fasten with a magnet. I
can't recreate the issue 100% of the time, but it does make sense that this is
the problem. 

I'll try to swap out my pouch for a different one, and see if the problem
persists.

Thanks!!!

(In reply to comment #17)
I was able to reliably reproduce the problem. I put the device in the carrying
case and then took it out 4 times in row. I took a dmesg dump just before and
just after the experiment, and indeed the usual messages are there (5
occurences of the "cover is open, card is now inaccessible).

As for the fsck from a PC, I don't have a microSD-compatible card reader,
unfortunately.

Comment 20 Eero Tamminen 2010-02-10 16:57:00 UTC

(In reply to comment #19)
> (In reply to comment #17)
> I was able to reliably reproduce the problem. I put the device in the carrying
> case and then took it out 4 times in row. I took a dmesg dump just before and
> just after the experiment, and indeed the usual messages are there (5
> occurences of the "cover is open, card is now inaccessible).

Thanks!  Assigning to Quim so that he can check what can be done about the
device documentation in regards to issues with magnets.  I don't think SW can
do more about this issue after the 51-1 release fixes to unmounting on back
cover open event.


> As for the fsck from a PC, I don't have a microSD-compatible card reader,
> unfortunately.

You can do that also from the device as root, after unmounting the file system.
 And your device should be providing it as USB mass storage device.

Comment 21 Andre Klapper 2010-03-01 21:19:27 UTC

Quim: ping? Any idea how to process here?

I also have this bug happening and also have a magnetic case for my N900.
However, my connection to the SD-card was lost via my Mac, though I can't be
100 % sure about that (since I had not checked Files (Tiedostot) before
connecting my N900 to the Mac). Thus, I've reconnected my N900 to the Mac via
USB-mode, when the computer told me that it couldn't mount the N900 but could
mount my SD. I removed the N900 from USB and reconnected it to the computer
again via USB-mode and managed to mount both N900 and the SD-card.

So for now I'll say what Nokia's staff told me earlier (before PR 1.1.1, which
I have now installed and haven't had this unmounting happening before it, I
think) : Don't use magnetic carrying cases with N900 for now, it can mess up
the phone (though this bug imo wouldn't be considered as proof since most of
answers seemed to be quite unsure?).

Thanks for the help though, I'll try to invest some money to non-magnetic
carrying case (though not Nokia's own one, it doesn't have top cover and thus
running could drop the phone).

Comment 23 Andre Klapper 2010-05-02 22:24:05 UTC

So does everybody running into this use a magnetic case? In that case the issue
is a WONTFIX:
"Issue is caused by a carrying case with magnetic clip that was tripping the
back cover magnetic sensor. => Hardware issue."

Comment 24 Andre Klapper 2010-08-26 19:03:43 UTC

So does everybody running into this use a magnetic case? In that case the issue
is a WONTFIX:
"Issue is caused by a carrying case with magnetic clip that was tripping the
back cover magnetic sensor. => Hardware issue."

That was certainly the case for me.

I agree with the "hardware issue" diagnostic, but I think it would make sense
to document this (as proposed in comment #20), possibly through a leaflet in
the device box, so that more users won't get bitten by this.

Carrying cases with magnetic flaps are quite common these days. I was able to
find something else (nylon + velcro), but it looks rubbish compared to the nice
black leather case I initially bought. I'm sure others will be tempted. And
it's not not obvious, when buying a phone, that you have to check the
compatibility with the carrying case (outside of size concerns, of course).

(In reply to comment #25)
> That was certainly the case for me.
> 
> I agree with the "hardware issue" diagnostic, but I think it would make sense
> to document this (as proposed in comment #20), possibly through a leaflet in
> the device box, so that more users won't get bitten by this.
> 
> Carrying cases with magnetic flaps are quite common these days. I was able to
> find something else (nylon + velcro), but it looks rubbish compared to the nice
> black leather case I initially bought. I'm sure others will be tempted. And
> it's not not obvious, when buying a phone, that you have to check the
> compatibility with the carrying case (outside of size concerns, of course).
> 

Yep, it was a issue with the case for me too and was resolved by exchanging the
case to another one. I agree and second the fact, that this should be mentioned
in the manual, if not already mentioned.

Comment 27 Andre Klapper 2010-08-30 14:17:19 UTC

Thans for the feedback. Closing as per comment 23/24.