Re: MMC/SD cards hotplug scenario
On Thu, 22 May 2008 19:10:10 +0530 Madhusudhan Chikkature Rajashekar [EMAIL PROTECTED] wrote: I am attaching the output of dmesg. I captured dmesg output after I get to the error phrase. I enabled MMC debugging as well to get some idea. It looks like upon reinsertion of the SD card, no commands are issued after CMD51. It might be the case where CMD51 (SD_APP_SEND_SCR) fails to read the SCR for some reason in this scenario. This looks like a driver/hw bug. CMD51 is the first data command in the init sequence, so the data engine of either the driver or hardware seems to be wedged. So it's not something related to the MMC core. Rgds Pierre signature.asc Description: PGP signature
RE: MMC/SD cards hotplug scenario
Hi Pierre, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pierre Ossman Sent: Thursday, May 22, 2008 12:02 AM To: Chikkature Rajashekar, Madhusudhan Cc: 'Russell King - ARM Linux'; linux-omap@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: MMC/SD cards hotplug scenario On Wed, 21 May 2008 15:01:00 +0530 Madhusudhan Chikkature Rajashekar [EMAIL PROTECTED] wrote: What I meant here is that reinsertion of the card does not seem to result in reinitialization of the card consistently. Previously, that has always been because of bad interactions with the block layer. 2.6.24 should be more resilient though. snip The obscene amount of noise here seems to be caused by ext2 being extremely persistent. This is generally a good thing for your data though. :) What is missing is a decent way for a block device to tell the upper layers that is gone with no hope of ever coming back. Right now we just tell it that there was a write error, which just makes the upper layers retry and retry. In this scenario, do you think it would be right to kill the ongoing copy from application space, say for example an UI is running for MMC copy and when the card is removed the app gets notified may be through hotplug event or signaling and then app just kills the process that is issuing this copy request. This will prevent long running errors. Just a thought, Regards, Khasim -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC/SD cards hotplug scenario
On Fri, May 23, 2008 at 01:16:39AM +0530, Syed Mohammed, Khasim wrote: The obscene amount of noise here seems to be caused by ext2 being extremely persistent. This is generally a good thing for your data though. :) What is missing is a decent way for a block device to tell the upper layers that is gone with no hope of ever coming back. Right now we just tell it that there was a write error, which just makes the upper layers retry and retry. In this scenario, do you think it would be right to kill the ongoing copy from application space, say for example an UI is running for MMC copy and when the card is removed the app gets notified may be through hotplug event or signaling and then app just kills the process that is issuing this copy request. This will prevent long running errors. Just a thought, If you pick out the errors from 'cp', you'll see that the system is telling 'cp' that it's getting IO errors. Nevertheless, 'cp' carries on trying to copy each file (and rightfully so.) However, there is another issue here - if you're going to be ejecting a medium containing an ext2fs filesystem at some random point, you absolutely must run e2fsck before remounting it - the filesystem _will_ be in an inconsistent state at the point you eject the card. Moreover, I wouldn't be surprised if you keep doing this with a card, that the card's firmware will eventually get confused and die. Basically, what I'm trying to say is that ejecting any medium randomly from the system is _always_ going to result in problems of some nature. Some of which you can reduce the impact from, others are fairly terminal. The only safe solution is the unmount, wait for data to be written, and then eject the card. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC/SD cards hotplug scenario
Hi, On Thu, 2008-05-22 at 21:01 +0100, ext Russell King - ARM Linux wrote: Basically, what I'm trying to say is that ejecting any medium randomly from the system is _always_ going to result in problems of some nature. Some of which you can reduce the impact from, others are fairly terminal. The only safe solution is the unmount, wait for data to be written, and then eject the card. from this point of view it is a watered down version of what happens when the power is removed abruptly, which unfortunately cannot really be avoided on battery powered devices with removable battery. If the system is supposed to survive such cases, then ext2 is probably not the best choice and a journaling fs (ext3 ?) should be considered. With MMC even the way the power fails (vcore fading away before/after vio) affects the possibility of the embedded uC b0rking. So it needs to be addressed also at board HW level. This of course cannot be really controlled when the MMC is removed from the slot, unless there is a sensor on the MMC lid. Sensor that could be used for an emergency, controlled powerdown, with no sync. But on the Tablets we instead show a warning and tell the user to be nice and close back the lid: UI designers prefer such approach. Just my 2 cents. -- Cheers, Igor --- Igor Stoppa Nokia Devices RD - Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC/SD cards hotplug scenario
On Wed, May 21, 2008 at 11:42:04AM +0530, Madhusudhan Chikkature Rajashekar wrote: After the end of the I/O errors I can umount the partition that was mounted and I reinsert the card. That's rather expected - outstanding IO has to be errored when the medium is removed. It seem not to work very well consistently. Vague handwaving comment with no useful information. What precisely is the problem that you're seeing? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MMC/SD cards hotplug scenario
-Original Message- From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 1:00 PM To: Madhusudhan Chikkature Rajashekar Cc: 'Pierre Ossman'; linux-omap@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: MMC/SD cards hotplug scenario On Wed, May 21, 2008 at 11:42:04AM +0530, Madhusudhan Chikkature Rajashekar wrote: After the end of the I/O errors I can umount the partition that was mounted and I reinsert the card. That's rather expected - outstanding IO has to be errored when the medium is removed. Yes. I got your point. But can this be made to through few I/O errors and stop instead of resulting in I/O errors for the rest of the data? In the case where data copied is huge, for eg 500MB, the I/O errors are quite lot. It seem not to work very well consistently. Vague handwaving comment with no useful information. What precisely is the problem that you're seeing? What I meant here is that reinsertion of the card does not seem to result in reinitialization of the card consistently. Details of few things I noticed is listed below stepwise and to start with card is detected and mounted on mount point /mnt/mmc dir. 1. Start copy of data. 2. Removed the card in the middle of transfer. At the controller driver level this generated card removed interrupt. The mmc_detect_change fn called. 3. I/O Errors generated. 4. Reinsert the card. This generated card inserted interrupt. The mmc_detect_fn called. But the card does not seem to be reinitialized correctly. cat /proc/partitions does not list mmc partitions. The attached log shows that out of 3 trails, it seem to work fine correctly 2 times and failed the third time. So my question is for the above scenario does the MMC/SD core need to take care of anything explicitely or should this be fixed at the controller driver level? Regards, Madhu p -a cp -a /etc/ /mnt/mmc/ + MMC CARD REMOVED + mmc0: card 981b removed mmcblk0: error -110 sending read/write command end_request: I/O error, dev mmcblk0, sector 3928 mmcblk0: error -110 sending read/write command end_request: I/O error, dev mmcblk0, sector 48 Buffer I/O error on device mmcblk0p1, logical block 4 lost page write due to I/O error on mmcblk0p1 mmcblk0: error -110 sending read/write command end_request: I/O error, dev mmcblk0, sector 16 Buffer I/O error on device mmcblk0p1, logical block 0 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 24 Buffer I/O error on device mmcblk0p1, logical block 1 lost page write due to I/O error on mmcblk0p1 mmcblk0: error -110 sending read/write command WARNING: at fs/buffer.c:1169 mark_buffer_dirty() [c0033400] (dump_stack+0x0/0x14) from [c00d21ac] (mark_buffer_dirty+0x44/0xb8) [c00d2168] (mark_buffer_dirty+0x0/0xb8) from [c0108ae4] (group_adjust_blocks+0x38/0x3c) r5:0008 r4: [c0108aac] (group_adjust_blocks+0x0/0x3c) from [c0109778] (ext2_new_blocks+0x3fc/0x5cc) [c010937c] (ext2_new_blocks+0x0/0x5cc) from [c010d100] (ext2_get_block+0x2bc/0x69c) [c010ce44] (ext2_get_block+0x0/0x69c) from [c00d2f70] (__block_prepare_write+0x18c/0x414) [c00d2de4] (__block_prepare_write+0x0/0x414) from [c00d32e4] (block_write_begin+0x90/0x108) [c00d3254] (block_write_begin+0x0/0x108) from [c010cdf4] (__ext2_write_begin+0x3c/0x48) [c010cdb8] (__ext2_write_begin+0x0/0x48) from [c010ce3c] (ext2_write_begin+0x3c/0x44) [c010ce00] (ext2_write_begin+0x0/0x44) from [c009185c] (generic_file_buffered_write+0x10c/0x5f0) [c0091750] (generic_file_buffered_write+0x0/0x5f0) from [c0092168] (__generic_file_aio_write_nolock+0x428/0x478) [c0091d40] (__generic_file_aio_write_nolock+0x0/0x478) from [c009222c] (generic_file_aio_write+0x74/0xe8) [c00921b8] (generic_file_aio_write+0x0/0xe8) from [c00b08d0] (do_sync_write+0xbc/0x10c) [c00b0814] (do_sync_write+0x0/0x10c) from [c00b11b8] (vfs_write+0xb8/0x148) [c00b1100] (vfs_write+0x0/0x148) from [c00b1784] (sys_write+0x44/0x70) r7:1000 r6:c7c1ff20 r5: r4: [c00b1740] (sys_write+0x0/0x70) from [c002ee60] (ret_fast_syscall+0x0/0x2c) r8:c002f66c r7:0004 r6:0004 r5:be8aa148 r4:1000 end_request: I/O error, dev mmcblk0, sector 1048592 Buffer I/O error on device mmcblk0p1, logical block 131072 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 1048600 Buffer I/O error on device mmcblk0p1, logical block 131073 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 1048608 Buffer I/O error on device mmcblk0p1, logical block 131074 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 1048616 Buffer I/O error on device mmcblk0p1, logical block 131075 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 1048624 Buffer I/O error on device mmcblk0p1, logical block 131076 lost page write due
Re: MMC/SD cards hotplug scenario
On Wed, 21 May 2008 15:01:00 +0530 Madhusudhan Chikkature Rajashekar [EMAIL PROTECTED] wrote: What I meant here is that reinsertion of the card does not seem to result in reinitialization of the card consistently. Previously, that has always been because of bad interactions with the block layer. 2.6.24 should be more resilient though. Details of few things I noticed is listed below stepwise and to start with card is detected and mounted on mount point /mnt/mmc dir. 1. Start copy of data. 2. Removed the card in the middle of transfer. At the controller driver level this generated card removed interrupt. The mmc_detect_change fn called. 3. I/O Errors generated. The obscene amount of noise here seems to be caused by ext2 being extremely persistent. This is generally a good thing for your data though. :) What is missing is a decent way for a block device to tell the upper layers that is gone with no hope of ever coming back. Right now we just tell it that there was a write error, which just makes the upper layers retry and retry. 4. Reinsert the card. This generated card inserted interrupt. The mmc_detect_fn called. But the card does not seem to be reinitialized correctly. cat /proc/partitions does not list mmc partitions. Anything in dmesg? So my question is for the above scenario does the MMC/SD core need to take care of anything explicitely or should this be fixed at the controller driver level? Host drivers shouldn't have to bother with any of this for the simple reason that there should be no state inside the driver except for the current request. Keeping track of cards and block devices are handled in the core and mmc_block respectively. Rgds Pierre signature.asc Description: PGP signature
