Re: strange problem with Intenso 4GB SDHC card
Andy Green wrote: [...] Hey don't lose hope. There are two issues. First is just some big cards are too slow to respond at default 16MHz clock with Glamo 16-bit clock count timeout counter. See this https://docs.openmoko.org/trac/ticket/1743 Suspend / resume (partition overwrite is only a suspend / resume issue) has been fundamentally broken on GTA02 since before I got here last December, it didn't work at all until a series of deathmatches with it. ~ The biggest deathmatch of all to clean and fix it is going on at the minute on 2.6.26 branch here and it exposed the biggest underlying problem for us which is Glamo behaviours. Assuming I kill it before it kills me, we will have a far less racy and more complete suspend and resume ordering situation then. yay! Other projects using Linux also have that problem of partition overwrite on resume, but I suspect resume ordering and racing is behind their problems too. When we clear that in the 2.6.26 branch we stand a chance to synthesize random or moving delays in resume action and try to flush out where it comes from. i played with it a bit and came to the conclusion that it eats exactly 1024byte from the beginning of the 'physical' blockdevice. atleast when i backup these to nand, write them back via dd after loosing it and do a ioctl via fdisk /dev/mmcblk0 - press w to trigger the block layer rereading the device i am fine. sounds weird.. is a buffer getting nulled on suspend, and gets written back to disk even if it shouldnt? -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | i played with it a bit and came to the conclusion that it eats exactly | 1024byte from the beginning of the 'physical' blockdevice. atleast when | i backup these to nand, write them back via dd after loosing it and do a | ioctl via fdisk /dev/mmcblk0 - press w to trigger the block layer | rereading the device i am fine. | | sounds weird.. is a buffer getting nulled on suspend, and gets written | back to disk even if it shouldnt? Huh. Well SD is predicated around 512 byte blocks, so it is a 2-block transaction. When I dump what the driver sees for requests, they are usually 2 or 8 512 byte blocks (1KBytes or 4KBytes). So that part isn't very foreign to the kind of transactions that are seen. In 2.6.24 the PMU is taken down real early in suspend, it yanks SD Card power (and CPU core power LOL) long before the MCI / MMC / SD driver and stack try to deselect the card nicely. One of the changes in andy-2.6.26 is to make Glamo (and other things) a child of the PMU, so the ordering is all changed around and SD Card can complete suspend sanely with the card still powered. The PMU goes down towards the end of all the suspend actions too which is much better considering CPU core power. The main striking thing about the SD Card overwrite issue for me is that we got rid of it for a long time just by removing the synchronous low level debug config... we could literally make this overwrite issue come and go by basically changing timing of suspend and resume actions alone. ~ So I believe that we deal with races at the heart of all this. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkigoaYACgkQOjLpvpq7dMqk/ACfXI+8eLkpvn9/QBd3i9COMIMf UH0An0Q0vm3BL+kN2CH4/7kvjK3tyyzU =UJPs -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Alle 01:16, sabato 26 luglio 2008, Thomas B. ha scritto: On Fri, Jul 25, 2008 at 11:44:37PM +0200, AVee wrote: On Friday 25 July 2008 10:54, arne anka wrote: i got a 4 gig card too (can't say if from intenso, have to check the wrapping). my card's boot sector is not erased but -- after a resume the card is mounted wrongly! fstab says as mountpoint /media/card and after booting that's where the card is. after suspend/resume the card (often) is mounted to /media/mmcblk1p1 instead -- thus every attempt to read from or write to the sd card goes to the built-in memory instead. I can confirm seeing the same behaviour with a Sandisk 8GB card... Me too (also Sandisk 8GB). It bit me while running Qtopia from SD card: Upon resuming the system crashed, probably because the rootfs was gone... I could reproduce this after having booted from flash. dmesg log of the suspend/resume cycle is attached. Regards, Thomas Any fix for this problem? I've made many test with a 4G SD. If use it for boot qtopia from vfat and ext2 partions it work fine. Slowly but fine. If I start system from 2007.2 in flash the mounted SD partitions give me many errors. Sometime was mounted 1st partion, sometime all of than. I've tried to access it in reading and writing and frequently I get I/O errors in dmesg. On time was loose partition table (in suspend/resume session). I've tried many partitions schemas (mixed FAT and ext2) but always I/O errors come. I've reformatted in a unique partition with FAT and I've filled in it about 1GB of maps for tangogps from my PC. The partition was mounted in /media/card and when tangogps start to read from SD some file was read good and many other not. The screen become full noised when SD is reading and get I/O errors. After the read go to end the screen come back showing fine. The 4GB SD with my PC work fine, no I/O errors. The 512M SD in FR package always work very well. The 4GB SD is a Apacer Micro SDHC 4GB Class 6. -- The sooner our happiness together begins, the longer it will last. -- Miramanee, The Paradise Syndrome, stardate 4842.6 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Andrew Burgess said (on the OLPC bug tracker): | | ...For me the SD card corruption is 100% fixed now. I run a swap to the | first sd card partition and I could guarantee partition wipe by turning | off power or shutting down with swap on. I could work around it 100% by | running swapoff before power down. I never enabled suspend. Now | everything works. It suspends and resumes at will with swap running. | Shutdown or mash the power button, partition table is fine... | | http://dev.laptop.org/ticket/6532#comment:63 What is the swap situation on the image you are running? I noticed Debian was doing something about it on initscripts, but I didn't notice before that we run swap on ASU? If as I believe this is very sensitive to a race, then not syncing swap can change the behaviour miles away from the swap itself and change the symptom, as could a bunch of other stuff. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiMJGQACgkQOjLpvpq7dMoBGQCfTZGoHzScbI+RtGdmKEtLlN0X 4fgAnjeHUc2iowstBWGgXmeVjd9kEr0k =uvX+ -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | With all ext2 partitions, I get this in dmesg | | FAT: bogus number of reserved sectors | VFS: Can't find a valid FAT filesystem on dev mmcblk0. | FAT: bogus number of reserved sectors | VFS: Can't find a valid FAT filesystem on dev mmcblk0. | JFFS2 warning: (956) jffs2_sum_write_sumnode: Not enough space for summary, | padsize = -1 | | a problem? No, it doesn't mean any problem about SD Card. First it tries to mount the thing vfat, before ext2 / 3, so those 4 lines are OK. Second the last line is ongoing jffs2 trouble that does not seem to make a symptom, when we move to 2.6.26 there is a at least one patch in there noticed by Holger that may impact this. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiMI5oACgkQOjLpvpq7dMqz2wCghkIiD+jxCd3mNgN2jyyVRC3C zyoAn1J/y1BvvzoJQcL4tr9EIYktjihl =eIaD -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Joerg Reisenweber wrote: snip As I think this seems to be quite a good clue to what's really happening here, quote from the OLPC ticket #6532: snip Yes, anybody working on this issue really ought to read that ticket in its entirety: http://dev.laptop.org/ticket/6532 (keeping in mind that some of the earlier entries, from months ago, may contain erroneous data) Note that some people think that this problem may affect things other than the SD card, and that external storage connected through USB might have a problem too. OLPC really really wants to do aggressive power management. They want to do things like halt the processor between keystrokes. If they can't do suspend and resume in 100 msec, they may not ever be able to deliver the holy grail: a laptop that can run for ten minutes on the power provided by one minute of muscle power from a four-year-old child. If they can achieve this, then OpenMoko ought to be able to achieve such aggressive power management too. That's how you get really long battery life. It seems that reconciling the need for data integrity on flash drives with the desire to achieve excellent power management is a hard problem. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | As I think this seems to be quite a good clue to what's really happening here, | quote from the OLPC ticket #6532: | (HTH) | cc dilinger added | I've spend some time digging deep into the bowels of the VFS and block layer | and gathering some debug output and have an explanation for the partition | table corruption: That's a great post you found Joerg and it is to the point. But what is killing me is this was working seemingly until we followed Sean McNeil's lead about removing printks of all things from PMU driver while trying to find the GSM crash in resume problem. That's not to blame his insight; clearly if we only work because async printks let it work, we're not really working at all. Previous to that, enabling synchronous low level debug in the kernel forced the bad behaviour and disabling it gave the good behaviour. This is ultimately a resume race of some kind, the VFS layer corruption and taking a whiz on block 0 (noticeable as it is) is downstream of whatever is truly responsible. I have made half the device a child of the PMU device now reflecting the relationship more clearly and this is honoured by the suspend / resume ordering now. It means that we still have power at the SD Card while glamo-mci driver is suspending, but we still fail to get a good result from the last command sent on suspend, cmd7 to deselect the card. I have to fix more problems today before I can see how MMC resumes from it. I'm also doing this on 2.6.26 in case MCI layer changes make a different result. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiKyrkACgkQOjLpvpq7dMpUbQCeK6fTmQRTf8A/Fm6Ze7Phiw/U YsYAn06RnSAuZbZUtRnP+56jY4Bau9OF =lJhb -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
i had the same problem here, with sandisk 8gb sdhc class 4 using ext2 partition. partition table was completley deleted :( hope this gets fixed soon. -- View this message in context: http://n2.nabble.com/strange-problem-with-Intenso-4GB-SDHC-card-tp579169p584908.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
David Meder-Marouelli [EMAIL PROTECTED] writes: After the the card settles (see above in this thread), i can do the following: 1) fdisk -l /dev/mmcblk0 Result: error 2) fdisk -l /dev/mmcblk0 Result: empty partition table!!! 3) fdisk -l /dev/mmcblk0 Result: correct full partition table!!! I can confirm the fdisk magic on my 4GB AData SDHC. It was partitioned with 4 ext2 partitions. Are these problems limited to only SDHC? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
thewtex [EMAIL PROTECTED] writes: David Meder-Marouelli [EMAIL PROTECTED] writes: After the the card settles (see above in this thread), i can do the following: 1) fdisk -l /dev/mmcblk0 Result: error 2) fdisk -l /dev/mmcblk0 Result: empty partition table!!! 3) fdisk -l /dev/mmcblk0 Result: correct full partition table!!! I can confirm the fdisk magic on my 4GB AData SDHC. It was partitioned with 4 ext2 partitions. Are these problems limited to only SDHC? With all ext2 partitions, I get this in dmesg FAT: bogus number of reserved sectors VFS: Can't find a valid FAT filesystem on dev mmcblk0. FAT: bogus number of reserved sectors VFS: Can't find a valid FAT filesystem on dev mmcblk0. JFFS2 warning: (956) jffs2_sum_write_sumnode: Not enough space for summary, padsize = -1 a problem? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
i got a 4 gig card too (can't say if from intenso, have to check the wrapping). my card's boot sector is not erased but -- after a resume the card is mounted wrongly! fstab says as mountpoint /media/card and after booting that's where the card is. after suspend/resume the card (often) is mounted to /media/mmcblk1p1 instead -- thus every attempt to read from or write to the sd card goes to the built-in memory instead. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | i got a 4 gig card too (can't say if from intenso, have to check the | wrapping). | my card's boot sector is not erased but -- after a resume the card is | mounted wrongly! | | fstab says as mountpoint /media/card and after booting that's where the | card is. | after suspend/resume the card (often) is mounted to /media/mmcblk1p1 | instead -- thus every attempt to read from or write to the sd card goes to | the built-in memory instead. This is definitely the signature of the old MMC resume problems, not anything else. I am deep down that mine at the minute, this is getting intensely looked at. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiJn8YACgkQOjLpvpq7dMonOACfTUfolw3wMrey+x51IwF/zl4W MxsAnjIkOZu9PLLGPZEX6L4l7a1g6x2d =vnNT -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
This is definitely the signature of the old MMC resume problems, not anything else. oh, ok. thought it to be related to the wiped out boot sector and thus maybe helpful. I am deep down that mine at the minute, this is getting intensely looked at. is there a workaround for the time being? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | This is definitely the signature of the old MMC resume problems, not | anything else. | | oh, ok. thought it to be related to the wiped out boot sector and thus | maybe helpful. It can be related, I expect the trashed block 0 thing is also suspend-related only. | I am deep down that mine at the minute, this is getting intensely looked | at. | | is there a workaround for the time being? Not that I know of. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiJrMsACgkQOjLpvpq7dMot8wCfXb8MuDMypvOB9u/wFNxtjkp6 n/gAn3HE4ZZ7BhlTbgeK5krC1ppHBQaM =Pyiu -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
btw: just checked and the default _device_ ist mmcblk0p1, after resume it disappears and instead there is mmcblk1p1. dunno if it is news to you ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
well, the card is a kingston 4gb class 4. yesterday i downloaded a map with tangogps and meanwhile the fr went to suspend. afterwards a few directories were misisng. trying ls /media/card/Maps/om/adirectorynotthere/ gives errors (something w/ read access i think) so i decided to delete the entire /media/card/Maps folder from within the fr -- but that fails with read-only filesystem. and indedd magically the card is mounted read only. mount /media/card -o remount,rw changes that, but next thing i know is read only filesystem. not sure if that fits into the original problem with the fried boot sector. is there a trac ticket where i may add those informations? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
On Friday 25 July 2008 10:54, arne anka wrote: i got a 4 gig card too (can't say if from intenso, have to check the wrapping). my card's boot sector is not erased but -- after a resume the card is mounted wrongly! fstab says as mountpoint /media/card and after booting that's where the card is. after suspend/resume the card (often) is mounted to /media/mmcblk1p1 instead -- thus every attempt to read from or write to the sd card goes to the built-in memory instead. I can confirm seeing the same behaviour with a Sandisk 8GB card... AVee -- I haven't lost my mind -- it's backed up on tape somewhere. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
On Fri, Jul 25, 2008 at 11:44:37PM +0200, AVee wrote: On Friday 25 July 2008 10:54, arne anka wrote: i got a 4 gig card too (can't say if from intenso, have to check the wrapping). my card's boot sector is not erased but -- after a resume the card is mounted wrongly! fstab says as mountpoint /media/card and after booting that's where the card is. after suspend/resume the card (often) is mounted to /media/mmcblk1p1 instead -- thus every attempt to read from or write to the sd card goes to the built-in memory instead. I can confirm seeing the same behaviour with a Sandisk 8GB card... Me too (also Sandisk 8GB). It bit me while running Qtopia from SD card: Upon resuming the system crashed, probably because the rootfs was gone... I could reproduce this after having booted from flash. dmesg log of the suspend/resume cycle is attached. Regards, Thomas PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.09 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Suspending console(s) pcf50633 0-0073: pcf50633_suspend glamo-mci glamo-mci.0: faking cmd 7 during suspend mmc_set_power(power_mode=0, vdd=0 glamo-mci glamo-mci.0: glamo_mci_set_ios: power down. gta02_udc_command(2) suspending dma channel 0 suspending dma channel 1 suspending dma channel 2 suspending dma channel 3 GSTATUS3 0x30376074 GSTATUS4 0x s3c2440-i2c s3c2440-i2c: slave address 0x10 s3c2440-i2c s3c2440-i2c: bus frequency set to 390 KHz gta02_udc_command(1) s3c2440-nand s3c2440-nand: Tacls=3, 30ns Twrph0=7 70ns, Twrph1=3 30ns not changing prescaler of PWM 3, since it's shared with timer4 (clock tick) timer_usec_ticks = 7864 timer tcon=00599109, tcnt a2c1, tcfg 0200,2000, usec 1eb8 mmc_set_power(power_mode=1, vdd=20 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: Error after cmd: 0x120 mmc0: card d555 removed MMC: killing requests for dead queue mmc_set_power(power_mode=0, vdd=0 glamo-mci glamo-mci.0: glamo_mci_set_ios: power down. mmc_set_power(power_mode=1, vdd=20 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x8120 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x8120 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 soc-audio soc-audio: scheduling resume work PM: Finishing wakeup. Restarting tasks ... 6soc-audio soc-audio: starting resume work glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). Bus width=2 mmc0: new high speed SDHC card at address d555 mmcblk1: mmc0:d555 SU08G 7977472KiB mmcblk1: p1 p2 p3 done. soc-audio soc-audio: resume work completed dma2: channel has nothing loaded EXT2-fs error (device mmcblk1): ext2_check_descriptors: Block bitmap for group 0 not in group (block 0)! EXT2-fs: group descriptors corrupted! EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Am Do 24. Juli 2008 schrieb Andy Green: Somebody in the thread at some point said: | Hi all, | | I can now reliably reproduce the issue, as dd'ing the mbr back to the | card so far restores sane behaviour : | | If sd_drive is set to 0, then after a resume from sync apm -s the | MBR of my 4GB SanDisk is wiped - so far I haven't noticed any other | errors, but have not looked very closely. ... | PS: Can somebody please tell me how to re-initialize the card without | going through another suspend/resume cycle ? sd_drive setting isn't actually used until next time we access the card, so provoking an access will do it, eg, touch /something ; sync. But the two explanations for what goes on seem mixed still here, we affect sd_drive and we do a suspend. My guess / hope is that this problem is coming from the suspend action alone and the change of sd_drive is bogus here. Maybe you can bang on it a little more trying to disprove that hypothesis? -Andy As I think this seems to be quite a good clue to what's really happening here, quote from the OLPC ticket #6532: (HTH) cc dilinger added I've spend some time digging deep into the bowels of the VFS and block layer and gathering some debug output and have an explanation for the partition table corruption: Upon coming out of resume, the SD code, with CONFIG_MMC_UNSAFE_SUSPEND enabled, checks to see if there is a card plugged into the system and whether that card is the same as the one that was plugged into the system at suspend time. This is accomplished by reading the card ID of the device and for some reason, very possibly #1339, we fail this detection. In this case, the kernel removes the old device from the system and in this execution path, the partition information for this device is zeroed. Even though the device is removed, the device is still mounted and upon unmount, ext2 syncs the superblock, even if the file system is sync'd beforehand. The superblock is block 0 of the partition and the block layer adds to this the partition start offset before submitting the write to the lower layers. As the partition information has already been zeroed out, we end up writing to block 0 of the disk itself, overwriting the partition table and the geometry information. I've verified this by both gathering debug output and 'dd' + 'hexdump' of corrupted and uncorrupted media. Some interesting points: We are able to delete a block device even though it is still mounted. Even though the device has been deleted, the write submitted to it does not fail. Note that this is still not 100% reproducible and in certain cases the superblock write during unmount does fail with block I/O errors, meaning that the queue is properly deleted. As per dilinger's comments on IRC, the VFS has lots of refcounts and there is a timing issue/race condition that we're hitting. As per #1339, we may be able to add an OLPC specific hackto wait 500ms or so upon resume to get around this. I will try this but I don't think this is acceptable given our suspend/resume requirements. Something I don't quite understand at the moment is how/when our userland env (journal specifically I think?) unmounts the device as I've been testing via command line suspend mount, and unmount while running in console mode. Next steps: Get an understanding of the what is happening with our userland and brainstorm with cjb about the possibility of simply unmounting the SD device upon suspend. There are issues around this as we may have files open and that will keep us from suspending. Test adding a timeout to the resume path to see if it solves our problem to validate that it is indeed something related to our HW. Dig into the unmount/write to non-existing bdev some more nad discuss this upstream if needed. (Adding dilinger to cc:) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Mikael Berthe wrote: * Doug Jones [EMAIL PROTECTED] [2008-07-24 01:21 +0200]: There have been some indications that partition type may have some effect on this problem on the OLPC. I doubt it. So, shrink the default vfat partition that came on the card and put an ext3 on there too. If you want to be adventurous, try some other types. Happens to me with ext3 partitions as well (or mixed vfat/ext3 partitions). However if I restore the partition table the data are not corrupted, at least so far it's been all right... Most people who use SD cards on OLPC are leaving them formatted as vfat, because Sugar can't see any other type. I don't recall seeing any reports of partition table mangling from these people, who are the vast majority of OLPC users. It's when they try something other than vfat that the corruption occurs. When it happened to me, I had one vfat and one ext3 on there. So on the OLPC at least, the corruption does seem to be correlated with partition type. Because the number of people trying different file systems on the SD card was relatively small, and because the corruption was happening sort of randomly, it's been difficult to figure out what's happening. Sample size too small. People were making all kinds of assumptions based on the limited reports, some of them wrong. If you look through that bug ticket and also various reports on forums and lists, you find contradictory information regarding which builds were affected, which file systems were affected, and so on. This kind of noise makes it a lot harder to debug. It's still not clear that this problem is understood, even six months later. This is why I suggested that lots of people try various file systems in their Neos, even if they don't need to have a card in there right now. If there is indeed an SD problem in the Neo, we need lots of reports, otherwise the sampling size problem might drag out the debugging for months as happened with OLPC. If there is no problem with SD, then there's no harm done. You'll just have a lot of people walking around with SD cards they aren't using yet sitting inside their phones. And of course it's entirely possible that the OLPC / SD problem has nothing to do with the Neo. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Everybody, get a Micro-SD card and stick it in your Neo. Put some should that apply to multiboot or to _every_ use of the sd card? i use suspend/resume more or less successfully for a week or 10 days now and the files on my sd card (4gb, how do i determine the exact name from a running system?) still are unharmed. gta02, 2007.2, upgrade every or every second day. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Hi all, I can now reliably reproduce the issue, as dd'ing the mbr back to the card so far restores sane behaviour : If sd_drive is set to 0, then after a resume from sync apm -s the MBR of my 4GB SanDisk is wiped - so far I haven't noticed any other errors, but have not looked very closely. To recover, I use the following commands: --- # re-write MBR dd if=mmcblk0_512_1.dump of=/dev/mmcblk0 # recognize partitions again echo 1/sys/module/glamo_mci/parameters/sd_drive apm -s So it looks as if the sd_drive parameter does have a role in this - any suggestions on what else I should try, or what logs you guys need ? Unmounting the card before suspend should help, and I'll also gladly try another kernel and other partitions setup if I find the time. Btw, this all happens on a 4GB SanDisk with 4 primary partitions: 20M vfat + (196M +196M +3.2G ) ext2 and kernel om-gta02 2.6.24 Wed Jul 23 06:34:19 Stefan PS: Can somebody please tell me how to re-initialize the card without going through another suspend/resume cycle ? On Thu, Jul 24, 2008 at 9:53 AM, arne anka [EMAIL PROTECTED] wrote: Everybody, get a Micro-SD card and stick it in your Neo. Put some should that apply to multiboot or to _every_ use of the sd card? i use suspend/resume more or less successfully for a week or 10 days now and the files on my sd card (4gb, how do i determine the exact name from a running system?) still are unharmed. gta02, 2007.2, upgrade every or every second day. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ices/platform/neo1973-button.0/input/input0 wake enabled for irq 48 s3c2440-ts s3c2440-ts: successfully loaded input: s3c2410 TouchScreen as /devices/virtual/input/input1 input: lis302-1 (top) as /devices/virtual/input/input2 lis302dl spi0.0: Found lis302-1 (top) input: lis302-2 (bottom) as /devices/virtual/input/input3 lis302dl spi0.1: Found lis302-2 (bottom) i2c /dev entries driver s3c2440-i2c s3c2440-i2c: slave address 0x10 s3c2440-i2c s3c2440-i2c: bus frequency set to 390 KHz s3c2440-i2c s3c2440-i2c: i2c-0: S3C I2C adapter input: GTA02 PMU events as /devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/input/input4 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 usb0: full speed config #1: 500 mA, Ethernet Gadget, using CDC Ethernet glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x8120 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x8120 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 wake enabled for irq 53 pcf50633: dev (254:0) pcf50633 0-0073: rtc core: registered pcf50633 as rtc0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). Bus width=2 mmc0: new high speed SDHC card at address d555 neo1973-pm-bt neo1973-pm-bt.0: FIC Neo1973 Bluetooth Power Management: starting neo1973-pm-gps neo1973-pm-gps.0: FIC Neo1973 GPS Power Managerment:starting APM Battery Driver bq27000-battery bq27000-battery.0: BQ27000 Battery Driver (C) 2008 Openmoko, Inc mmcblk0: mmc0:d555 SU04G 3979776KiB mmcblk0: p1 p2 p3 p4 S3c2440 SDIO Host controller SDIO BusDriver - SDIO_GetBusOSDevice, registering driver: sdio_s3c24xx_hcd DMAmask: 0x0 pnp: the driver 'sdio_s3c24xx_hcd' has been registered mapped channel 0 to 0 S3c24xx SDIO: IRQ:37 Detect IRQ:0 DMA channel:0 [EMAIL PROTECTED] [EMAIL PROTECTED] kHz SDIO Bus Driver: HCD:sdio_s3c24xx should set module ptr! sdio_s3c24xx_hcd 00:00: driver attached sdio_s3c24xx_hcd 00:00: SDIO device, IDs SD_0008 (active) pnp: the driver 'sdio_wlan' has been registered Registered led device: neo1973:vibrator Registered led device: gta02-power:orange Registered led device: gta02-power:blue Registered led device: gta02-aux:red TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. pcf50633 0-0073: setting system clock to 2008-07-24 12:59:39 UTC (1216904379) Using lowest clock rate CRCFAIL 0x1a3f
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Hi all, | | I can now reliably reproduce the issue, as dd'ing the mbr back to the | card so far restores sane behaviour : | | If sd_drive is set to 0, then after a resume from sync apm -s the | MBR of my 4GB SanDisk is wiped - so far I haven't noticed any other | errors, but have not looked very closely. ... | PS: Can somebody please tell me how to re-initialize the card without | going through another suspend/resume cycle ? sd_drive setting isn't actually used until next time we access the card, so provoking an access will do it, eg, touch /something ; sync. But the two explanations for what goes on seem mixed still here, we affect sd_drive and we do a suspend. My guess / hope is that this problem is coming from the suspend action alone and the change of sd_drive is bogus here. Maybe you can bang on it a little more trying to disprove that hypothesis? - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiIbpQACgkQOjLpvpq7dMoFygCfagDp2oeJBH3TWSCtzgfeKiBX SOkAnibMEKKHWCf7w5UDCp+9Jy2V8aqj =FgHS -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Hi Stefan, maybe it turn out to be the same problem that I also have. After the the card settles (see above in this thread), i can do the following: 1) fdisk -l /dev/mmcblk0 Result: error 2) fdisk -l /dev/mmcblk0 Result: empty partition table!!! 3) fdisk -l /dev/mmcblk0 Result: correct full partition table!!! [Note: nothing else changed in between] To re-ead the partition table just start fdisk /dev/mmcblk0, verify that partition table is ok with p, re-write unaltered partition table with w. After that it's re-read by the kernel and the Frerunner recognises it. Cheers, David Stefan Fröbe schrieb: Hi all, I can now reliably reproduce the issue, as dd'ing the mbr back to the card so far restores sane behaviour : If sd_drive is set to 0, then after a resume from sync apm -s the MBR of my 4GB SanDisk is wiped - so far I haven't noticed any other errors, but have not looked very closely. To recover, I use the following commands: --- # re-write MBR dd if=mmcblk0_512_1.dump of=/dev/mmcblk0 # recognize partitions again echo 1/sys/module/glamo_mci/parameters/sd_drive apm -s So it looks as if the sd_drive parameter does have a role in this - any suggestions on what else I should try, or what logs you guys need ? Unmounting the card before suspend should help, and I'll also gladly try another kernel and other partitions setup if I find the time. Btw, this all happens on a 4GB SanDisk with 4 primary partitions: 20M vfat + (196M +196M +3.2G ) ext2 and kernel om-gta02 2.6.24 Wed Jul 23 06:34:19 Stefan PS: Can somebody please tell me how to re-initialize the card without going through another suspend/resume cycle ? On Thu, Jul 24, 2008 at 9:53 AM, arne anka [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Everybody, get a Micro-SD card and stick it in your Neo. Put some should that apply to multiboot or to _every_ use of the sd card? i use suspend/resume more or less successfully for a week or 10 days now and the files on my sd card (4gb, how do i determine the exact name from a running system?) still are unharmed. gta02, 2007.2, upgrade every or every second day. ___ Openmoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Hi David, After the the card settles (see above in this thread), i can do the following: 1) fdisk -l /dev/mmcblk0 Result: error ... No matter how often I call this, it never changes as the MBR is completely zeroed out. To re-ead the partition table just start fdisk /dev/mmcblk0, verify that partition table is ok with p, re-write unaltered partition table with w. After that it's re-read by the kernel and the Frerunner recognises it. That works great after I dd the mbr back, thanks for the pointer! Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Hi Andy, sd_drive setting isn't actually used until next time we access the card, so provoking an access will do it, eg, touch /something ; sync. Good point, but now it is getting really strange (all with sd_drive=0 prior to suspend): Adding a touch /media/mmcblk0p4/suspending and it works, also adding the sync and it doesn't, and finally also adding a sleep 1 to the line and it gives me mixed results. Maybe it is a timing issue, and the previously mentioned 400-500ms delay is needed? But the two explanations for what goes on seem mixed still here, we affect sd_drive and we do a suspend. My guess / hope is that this problem is coming from the suspend action alone and the change of sd_drive is bogus here. Maybe you can bang on it a little more trying to disprove that hypothesis? Will do if I find the time, but for now completely unmounting the card seems like the only viable solution apart from dd'ing mbrs back and forth until the root cause is found... Hopefully the data storage on card is not impeded, but personally I will do backups more often now ;-) ... STefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
I experienced the same issue with my card (also the A-Data 8GB) after flashing the kernel and rootfs builds from the 22nd. My partition table seems to have been deleted. I'm pretty sure it happened after a suspend/resume cycle (what happens when you have power management set to dim first, then lock). I had a vfat and an ext3 partition on there that I was using to dual-boot. Is there a bug report/ticket for this issue I should be adding to? At the very least, doesn't this belong on the support mailing list instead of community? -Steven On Wed, Jul 23, 2008 at 5:20 PM, Matt Luzum [EMAIL PROTECTED] wrote: Andy Green wrote: There's a race of some kind in suspend / resume that can do this, the signature effect of it is on resume your device comes back as mmcblk1 and the logical filesystem in memory is corrupted. We didn't see this for a long time though. Maybe keep an eye out for such shenanigans on resume. I just thought I'd mention that I had a similar thing happen. Three times in the past couple days, my 8 GB A-Data microSDHC card somehow seemed to have its partition table deleted. No partitions would show up on my card anyway, although I could make new partitions and read and write from them with a card reader. I haven't had time to investigate more thoroughly, so I don't know whether it happens on resume or if it only happens when I'm doing something in particular. I've had the original half gig card in there since yesterday and it hasn't had any problems, even though the SDHC card previously had problems several times in short order, so there might be some difference there. Sorry I can't be of more help with specifics, but I can confirm that there's someone else having this problem. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Does anyone know an equivalent tool for Linux? fdisk just says unable to open. So, I can't even re-write the data to the card. It's just dead! -Steven On Wed, Jul 23, 2008 at 4:15 PM, Stefan Fröbe [EMAIL PROTECTED] wrote: Hi, just a quick observation from my side that could possibly be related: Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g. 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got me a new kernel I was surprised to see the card not beeing recognized anymore - furthermore, its MBR was zeroed out, and no tool could read or reformat it except a SD-Card recovery tool by Panasonic ( sdfv2003.exe running only under Windows, of course ) ! I now backup'ed the partition table and mbrs in hope to be able to dd it back, should this happen again. Sorry, but I haven't got any logs as I was busy recovering what was left, but I'll surly save them next time ... Stefan uname -a Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl unknown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Nevermind. Gparted could read it. -Steven On Thu, Jul 24, 2008 at 6:37 PM, Steven ** [EMAIL PROTECTED] wrote: Does anyone know an equivalent tool for Linux? fdisk just says unable to open. So, I can't even re-write the data to the card. It's just dead! -Steven On Wed, Jul 23, 2008 at 4:15 PM, Stefan Fröbe [EMAIL PROTECTED] wrote: Hi, just a quick observation from my side that could possibly be related: Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g. 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got me a new kernel I was surprised to see the card not beeing recognized anymore - furthermore, its MBR was zeroed out, and no tool could read or reformat it except a SD-Card recovery tool by Panasonic ( sdfv2003.exe running only under Windows, of course ) ! I now backup'ed the partition table and mbrs in hope to be able to dd it back, should this happen again. Sorry, but I haven't got any logs as I was busy recovering what was left, but I'll surly save them next time ... Stefan uname -a Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl unknown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
On Thursday 24 July 2008 08:39, Doug Jones wrote: Mikael Berthe wrote: * Doug Jones [EMAIL PROTECTED] [2008-07-24 01:21 +0200]: There have been some indications that partition type may have some effect on this problem on the OLPC. I doubt it. So, shrink the default vfat partition that came on the card and put an ext3 on there too. If you want to be adventurous, try some other types. Happens to me with ext3 partitions as well (or mixed vfat/ext3 partitions). However if I restore the partition table the data are not corrupted, at least so far it's been all right... Most people who use SD cards on OLPC are leaving them formatted as vfat, because Sugar can't see any other type. I don't recall seeing any reports of partition table mangling from these people, who are the vast majority of OLPC users. It's when they try something other than vfat that the corruption occurs. When it happened to me, I had one vfat and one ext3 on there. So on the OLPC at least, the corruption does seem to be correlated with partition type. I haven't been able to find a publicly available version of any SD Card or SDHC spec. But both of the documents below seem to suggest that fat32 is part of the specification: http://www.sdcard.org/about/sdhc/ http://www.kingston.com/flash/pdf_files/MKF_1127_SDHC_Topic_Paper.pdf If that is the case both the controller and logic on the card may assume it contains a single full-size fat32 partition. They surely will not be tested with anything other then fat32. Does anyone here have access to official specs from the SDCard Association? It be interesting to have at least a hint about what the spec says about partitioning... AVee -- I always finish what I... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
strange problem with Intenso 4GB SDHC card
Hi, I observed an interesting phenomenon with my newly bought Intenso 4GB SDHC card. While the 512MB card shipped with my Freerunner runs reliably and stable the new card shows the following behaviour: 1) Errors during boot process: [EMAIL PROTECTED]:~# dmesg |grep -E glamo|mmc glamo3362 glamo3362.0: Detected Glamo core 3650 Revision 0002 (49119232Hz CPU / 81887232Hz Memory) glamo3362 glamo3362.0: Glamo core now 49119232Hz CPU / 81887232Hz Memory) glamo-spi-gpio glamo-spi-gpio.0: registering c0373838: jbt6k74 glamo-mci glamo-mci.0: glamo_mci driver (C)2007 Openmoko, Inc glamo-mci glamo-mci.0: probe: mapped mci_base:c8864400 irq:0. glamo-mci glamo-mci.0: glamo_mci_set_ios: power down. glamo-mci glamo-mci.0: initialisation done. mmc_set_power(power_mode=1, vdd=20 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x8120 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x8120 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). Bus width=2 mmc0: new high speed SDHC card at address b368 mmcblk0: mmc0:b368 SD3931136KiB mmcblk0:6glamo-mci glamo-mci.0: Error after cmd: 0x8310 mmcblk0: error -110 sending read/write command end_request: I/O error, dev mmcblk0, sector 0 Buffer I/O error on device mmcblk0, logical block 0 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x122 mmcblk0: error -84 sending read/write command [many more of the last few lines following] 2) I can trick it to work doing the following steps: - check sd_drive parameter (not required) [EMAIL PROTECTED]:~# cat /sys/module/glamo_mci/parameters/sd_drive 0 - re-set it to this (or possibly any other) value [EMAIL PROTECTED]:~# echo 0 /sys/module/glamo_mci/parameters/sd_drive - now the device works fine: [EMAIL PROTECTED]:~# fdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes 126 heads, 61 sectors/track, 1022 cylinders Units = cylinders of 7686 * 512 = 3935232 bytes Device Boot Start End Blocks Id System /dev/mmcblk0p1 11022 3927515+ 83 Linux == A suspend/resume cycle seems to do the trick as well. I think that some parameter connected to sd_drive might be uninitialised before sd_drive is explicitly rewritten. Any ideas? Cheers, David ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | glamo-mci glamo-mci.0: Error after cmd: 0x120 | glamo-mci glamo-mci.0: Error after cmd: 0x8120 | glamo-mci glamo-mci.0: Error after cmd: 0x120 | glamo-mci glamo-mci.0: Error after cmd: 0x8120 | glamo-mci glamo-mci.0: Error after cmd: 0x120 This bit is normal, it's the Linux MMC / SD stack seeing if it is an SDIO card. | glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: | 1kHz). Bus width=2 This bit is a good sign, it was able to complete getting recognized by the stack and put into 4-bit mode at 16MHz SD_CLK. | mmc0: new high speed SDHC card at address b368 | mmcblk0: mmc0:b368 SD3931136KiB | mmcblk0:6glamo-mci glamo-mci.0: Error after cmd: 0x8310 | mmcblk0: error -110 sending read/write command This first real error is ETIMEDOUT. It can be a genuine timeout because your card is a bit slow, but it could also mean communication problems. | 2) I can trick it to work doing the following steps: |- check sd_drive parameter (not required) | [EMAIL PROTECTED]:~# cat /sys/module/glamo_mci/parameters/sd_drive | 0 |- re-set it to this (or possibly any other) value | [EMAIL PROTECTED]:~# echo 0 /sys/module/glamo_mci/parameters/sd_drive |- now the device works fine: I don't see how that can impact it, none of our code runs when you change that, it simply gets written to the int that holds sd_drive behind our back. And when you catted it, that is the real value of that int, it doesn't keep a copy somewhere. Maybe something else in the threshing around helped. | [EMAIL PROTECTED]:~# fdisk -l /dev/mmcblk0 | | Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes | 126 heads, 61 sectors/track, 1022 cylinders | Units = cylinders of 7686 * 512 = 3935232 bytes | | Device Boot Start End Blocks Id System | /dev/mmcblk0p1 11022 3927515+ 83 Linux | == | | A suspend/resume cycle seems to do the trick as well. | I think that some parameter connected to sd_drive might be uninitialised | before sd_drive is explicitly rewritten. I don't see it can be uninitialzed data, it is more likely working or not working according to its own plan. Once you formatted it, can you write reliably to it and read stuff back with same md5sum after umount to flush the cache? - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiHkqcACgkQOjLpvpq7dMpeOwCfWfNTye1954C23FKy6aA7lvg+ fSgAnjun7jOgrNFnzuWu2yT//YFwuVEl =wt0V -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Hi Andy, thanks for the quick reply. Andy Green schrieb: | mmc0: new high speed SDHC card at address b368 | mmcblk0: mmc0:b368 SD3931136KiB | mmcblk0:6glamo-mci glamo-mci.0: Error after cmd: 0x8310 | mmcblk0: error -110 sending read/write command This first real error is ETIMEDOUT. It can be a genuine timeout because your card is a bit slow, but it could also mean communication problems. Not really good timing would probably be a good guess since Intenso is a low cost brand around here (germany). | 2) I can trick it to work doing the following steps: |- re-set it to this (or possibly any other) value | [EMAIL PROTECTED]:~# echo 0 /sys/module/glamo_mci/parameters/sd_drive Thanks for your guidance. It's _not_ the sd_drive parameter. It's actually just waiting for about 1-2min. After that the device is readily accessible. (Need to force a re-read of the partition table to mount though.) Anyways I made sure that the data I wrote to the card yesterday is still OK (md5sum) - although it's only around 1MB. I can do more tests tomorrow... Cheers, David ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Hi, just a quick observation from my side that could possibly be related: Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g. 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got me a new kernel I was surprised to see the card not beeing recognized anymore - furthermore, its MBR was zeroed out, and no tool could read or reformat it except a SD-Card recovery tool by Panasonic ( sdfv2003.exe running only under Windows, of course ) ! I now backup'ed the partition table and mbrs in hope to be able to dd it back, should this happen again. Sorry, but I haven't got any logs as I was busy recovering what was left, but I'll surly save them next time ... Stefan uname -a Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl unknown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Hi, | | just a quick observation from my side that could possibly be related: | Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g. | 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got | me a new kernel I was surprised to see the card not beeing recognized | anymore - furthermore, its MBR was zeroed out, and no tool could read or | reformat it except a SD-Card recovery tool by Panasonic ( sdfv2003.exe | running only under Windows, of course ) ! | | I now backup'ed the partition table and mbrs in hope to be able to dd it | back, should this happen again. Sorry, but I haven't got any logs as I | was busy recovering what was left, but I'll surly save them next time ... There's a race of some kind in suspend / resume that can do this, the signature effect of it is on resume your device comes back as mmcblk1 and the logical filesystem in memory is corrupted. We didn't see this for a long time though. Maybe keep an eye out for such shenanigans on resume. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiHqaMACgkQOjLpvpq7dMpmjACeLCn3EHaubbZvLQWiBOqbJEIC X1kAnipwM3etDG0tcQbVWArQuNNbV1vp =qSZM -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Stefan Fröbe wrote: Hi, just a quick observation from my side that could possibly be related: Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g. 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got me a new kernel I was surprised to see the card not beeing recognized anymore - furthermore, its MBR was zeroed out, and no tool could read or reformat it except a SD-Card recovery tool by Panasonic ( sdfv2003.exe running only under Windows, of course ) ! I now backup'ed the partition table and mbrs in hope to be able to dd it back, should this happen again. Sorry, but I haven't got any logs as I was busy recovering what was left, but I'll surly save them next time ... Stefan uname -a Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl unknown Not sure if this is connected with what you are seeing, but... Something similar has been happening with SD cards on the OLPC laptop (another example of hardware specifically designed for the FOSS world) for at least the last six months. Last time I checked, there was still no real fix. Has been a major pain for people who want to multiboot -- forces them to use storage devices that don't fit inside the case. http://dev.laptop.org/ticket/6532 I am getting the impression that interfacing to SD cards is hard. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Andy Green wrote: There's a race of some kind in suspend / resume that can do this, the signature effect of it is on resume your device comes back as mmcblk1 and the logical filesystem in memory is corrupted. We didn't see this for a long time though. Maybe keep an eye out for such shenanigans on resume. I just thought I'd mention that I had a similar thing happen. Three times in the past couple days, my 8 GB A-Data microSDHC card somehow seemed to have its partition table deleted. No partitions would show up on my card anyway, although I could make new partitions and read and write from them with a card reader. I haven't had time to investigate more thoroughly, so I don't know whether it happens on resume or if it only happens when I'm doing something in particular. I've had the original half gig card in there since yesterday and it hasn't had any problems, even though the SDHC card previously had problems several times in short order, so there might be some difference there. Sorry I can't be of more help with specifics, but I can confirm that there's someone else having this problem. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Thanks for the link, seems to be quite valuable to me as it explains the background quite well! Something similar has been happening with SD cards on the OLPC laptop (another example of hardware specifically designed for the FOSS world) for at least the last six months. Last time I checked, there was still no real fix. Well, from recent comments it looks like a 400ms delay (yuck!) in drivers/mmc/core/sd.c is a temporary workaround, but the root cause (as Andy already suggested) seems to be related to the resume cycle. Has been a major pain for people who want to multiboot -- forces them to use storage devices that don't fit inside the case. http://dev.laptop.org/ticket/6532 At least it doesn't look like a HW issue with the card, then. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Thanks for the link, seems to be quite valuable to me as it explains the | background quite well! | | Something similar has been happening with SD cards on the OLPC laptop | (another example of hardware specifically designed for the FOSS world) | for at least the last six months. Last time I checked, there was still | no real fix. | | | Well, from recent comments it looks like a 400ms delay (yuck!) in | drivers/mmc/core/sd.c is a temporary workaround, but the root cause (as | Andy already suggested) seems to be related to the resume cycle. | | Has been a major pain for people who want to multiboot -- | forces them to use storage devices that don't fit inside the case. | | http://dev.laptop.org/ticket/6532 | | | At least it doesn't look like a HW issue with the card, then. Yes when we originally had this problem I found OLPC had it and indeed Eee PC at that time. What cured it for us was removing the low level debug config option in the kernel, but that really is all about changing timing too. There's another complicated problem that can be related about the relationship between the PMU and the Glamo. The PMU device is only created really late in boot because it is on I2C bus. That means it is suspended very early in suspend, yanking a lot of power rails (including the CPU core power! But it goes on long enough from caps) before the MMC stack has a chance to talk to the card and close it down gently. Although suspend / resume has been acting well these last weeks it is fragile and we'll be doing a lot more work on it. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiHtWgACgkQOjLpvpq7dMqZIQCgkQdTUr6+4RrgkvCVG3fgWt3y Od0AmwTQhXUu0Iklzfbi+1f0I4oWn3kT =q9q1 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Stefan Fröbe wrote: Thanks for the link, seems to be quite valuable to me as it explains the background quite well! Something similar has been happening with SD cards on the OLPC laptop (another example of hardware specifically designed for the FOSS world) for at least the last six months. Last time I checked, there was still no real fix. Well, from recent comments it looks like a 400ms delay (yuck!) in drivers/mmc/core/sd.c is a temporary workaround, but the root cause (as Andy already suggested) seems to be related to the resume cycle. Has been a major pain for people who want to multiboot -- forces them to use storage devices that don't fit inside the case. http://dev.laptop.org/ticket/6532 At least it doesn't look like a HW issue with the card, then. Stefan Just spent some time looking at that bug ticket again. I've been trying to follow this story ever since my OLPC trashed the partition table on my 16GB SDHC card back in January. A consensus seems to be building that suspend/resume is involved. But I don't think anybody really understands what's going on, and people have been bashing their heads against this again and again for six months. If something like this is happening in the Neo, then this could turn into a world of hurt. Recommendation: Everybody, get a Micro-SD card and stick it in your Neo. Put some random files on it, you don't have to do anything serious with it, just let it sit in there for a while. Periodically check that you can still see those files. If you lose those files, post about it. Maybe we should start a new thread to keep track of this data. There have been some indications that partition type may have some effect on this problem on the OLPC. So, shrink the default vfat partition that came on the card and put an ext3 on there too. If you want to be adventurous, try some other types. If more people start seeing problems like this, we ought to start comparing notes with the OLPC people who are working on this. And Pierre Ossman too, he did a lot of work on SD support in the kernel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
* Doug Jones [EMAIL PROTECTED] [2008-07-24 01:21 +0200]: There have been some indications that partition type may have some effect on this problem on the OLPC. I doubt it. So, shrink the default vfat partition that came on the card and put an ext3 on there too. If you want to be adventurous, try some other types. Happens to me with ext3 partitions as well (or mixed vfat/ext3 partitions). However if I restore the partition table the data are not corrupted, at least so far it's been all right... -- MiKael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
