On Wed, 21 May 2008 15:01:00 +0530 "Madhusudhan Chikkature Rajashekar" <madhu.cr@xxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
