Find below diff :
--- queue.c 2010-07-13 13:52:53.000000000 +0530
+++ queue_2_6_34.c 2010-07-13 13:54:35.000000000 +0530
@@ -236,17 +236,18 @@ void mmc_cleanup_queue(struct mmc_queue
struct request_queue *q = mq->queue;
unsigned long flags;
- /* Mark that we should start throwing out stragglers */
- spin_lock_irqsave(q->queue_lock, flags);
- q->queuedata = NULL;
- spin_unlock_irqrestore(q->queue_lock, flags);
-
/* Make sure the queue isn't suspended, as that will deadlock */
mmc_queue_resume(mq);
/* Then terminate our worker thread */
kthread_stop(mq->thread);
+ /* Empty the queue */
+ spin_lock_irqsave(q->queue_lock, flags);
+ q->queuedata = NULL;
+ blk_start_queue(q);
+ spin_unlock_irqrestore(q->queue_lock, flags);
+
if (mq->bounce_sg)
kfree(mq->bounce_sg);
mq->bounce_sg = NULL;
@@ -258,8 +259,6 @@ void mmc_cleanup_queue(struct mmc_queue
kfree(mq->bounce_buf);
mq->bounce_buf = NULL;
- blk_cleanup_queue(mq->queue);
-
mq->card = NULL;
}
EXPORT_SYMBOL(mmc_cleanup_queue);
In card detect interrupt handler we have use tasklet.... no my Host
controller does not support SDHCI.
On Tue, Jul 13, 2010 at 11:37 AM, MADHAV SINGHCHAUHAN
<singh.madhav@xxxxxxxxxxx> wrote:
>
> Hi Madhav,
>
> I have change the card remove sequence as per latest kernel source
> 2.6.34 .... after changing this i face the same issue.... is there any
> way to check card detect status at block layer ? or any other way to
> avoid it ....
>>>Can i see your changes made by you..paste your diff here....Also even though you change ur card detect sequence
> still you will get these messages ,,but somewhat you can reduce these messages if ur card removal sequence is efficient..
> By the way does your Host controller support SDHCI??What you use in card detect interrupt handler workqueue or tasklet??
> After removing card .... when i execute any command on board then also
> i got below error messages :
>>>Once you remove your card and if you still execute any command in the mount point of the card
> you will get these type of errors ...ignore them...
>
> FAT: Directory bread(block 3898) failed
> FAT: Directory bread(block 3899) failed
> FAT: Directory bread(block 3900) failed
> FAT: Directory bread(block 3901) failed
> FAT: Directory bread(block 3902) failed
> On Mon, Jul 12, 2010 at 2:28 PM, MADHAV SINGHCHAUHAN
> <singh.madhav@xxxxxxxxxxx> wrote:
>>
>>
>>
>> I am using 2.6.30 linux kernel version ...
>>>>As i told you previously that you need to flush queue as soon as possible once you remove the card.
>> So once you remove card mmc_blk_remove() gets called which calls mmc_cleanup_queue() and it further intenally calls
>> kthread_stop()(stops thread which process requests).So compare the latest kernel version wrt your kernel version
>> and you will find the differences in card remove sequence so either you can backport these functions or change manually
>> sequence of these functions.
>>
>> On Fri, Jul 9, 2010 at 9:20 AM, Madhav Chauhan <madhav.imsec@xxxxxxxxx> wrote:
>>> On Thu, Jul 8, 2010 at 11:38 PM, hardik patel <hk5patel@xxxxxxxxx> wrote:
>>>> Hi Madhav,
>>>>
>>>> thanks for your interest... I have card detect register so mmc_get_cd
>>>> function i can check whether card is inserted or not ... so in sd host
>>>> controller driver can detect that properly... but i think block driver
>>>> does not detect that .... where i have to flush my request queue... i
>>>> have gone through block.c and queue.c file which generate mmc_block.ko
>>>> file but not sure where to modify... can any one guide me more
>>>
>>> Which Kernel version you are using??
>>>>
>>>>
>>>> On Thu, Jul 8, 2010 at 6:35 PM, MADHAV SINGHCHAUHAN
>>>> <singh.madhav@xxxxxxxxxxx> wrote:
>>>>> Card removal not detected by driver?
>>>>> You should see a line of log if card removal is detected:
>>>>> card xxxx removed
>>>>>
>>>>> Would you describe how do you detect card removal/insertion on your board?
>>>>>
>>>>> Regards,
>>>>> -Ethan
>>>>>
>>>>> On Thu, Jul 8, 2010 at 6:05 PM, hardik patel <hk5patel@xxxxxxxxx> wrote:
>>>>>> I have sd card on board ... During recording/writing SD card, remove
>>>>>> SD card ... then i am getting endless error in dmesg as below :
>>>>>>
>>>>>> end_request: I/O error, dev mmcblk0, sector 24
>>>>>> FAT: FAT read failed (blocknr 8)
>>>>>> mmcblk0: error -110 sending status comand<3>mmcblk0: error -110
>>>>>> sending read/write command, response 0x0, card status 0x0
>>>>>> Block mmc_blk_issue_rq function call 346
>>>>>> end_request: I/O error, dev mmcblk0, sector 4
>>>>>> FAT: FAT read failed (blocknr 4)
>>>>>> MMC: killing requests for dead queue
>>>>>> end_request: I/O error, dev mmcblk0, sector 8
>>>>>> FAT: FAT read failed (blocknr 8)
>>>>>> FAT: FAT read failed (blocknr 4)
>>>>>> FAT: FAT read failed (blocknr 8)
>>>>>> FAT: FAT read failed (blocknr 4)
>>>>>> FAT: FAT read failed (blocknr 8)
>>>>>> FAT: FAT read failed (blocknr 4)
>>>>>> FAT: FAT read failed (blocknr 8)
>>>>>>
>>>>>> How to stop this message ... what is ideal situation when we remove
>>>>>> card while writing ...... can u help me what to do ?
>>>>>>
>>>>>>>When we insert the card hot plug dameon start sending the request to block layer and kernel block layer
>>>>>>>start sending the request to card.But when you remove the card in between request queue is not flushed properly..
>>>>>>>so you need to flush your request queue at appropriate time.Also please note that even that you flush your request queue
>>>>>>>at appropriate time some messages will come.
>>>>>> where is the problem here? sd host controler driver problem or block
>>>>>> driver problem or file system problem
>>>>>>
>>>>>> Note: I have formatted sd card with FAT32 file system .
>>>>>>
>>>>>>
>>>>>>
>>>>>> With EXT3 File system :
>>>>>>
>>>>>> Remove SD card while writing/recording we got error messages like
>>>>>> below. but this is not endless. After some time it stops.
>>>>>>
>>>>>> ==============================
>>>>>> =============
>>>>>> end_request: I/O error, dev mmcblk0, sector 156536
>>>>>> mmcblk0: error -110 sending status comand<3>mmcblk0: error -110
>>>>>> sending read/write command, response 0x0, card status 0x0
>>>>>> mmcblk0: error -110 requesting status
>>>>>> end_request: I/O error, dev mmcblk0, sector 4736
>>>>>> Aborting journal on device mmcblk0p1.
>>>>>> ext3_abort called.
>>>>>> EXT3-fs error (device mmcblk0p1): ext3_journal_start_sb: Detected
>>>>>> aborted journal
>>>>>> Remounting filesystem read-only
>>>>>> end_request: I/O error, dev mmcblk0, sector 4448
>>>>>> journal commit I/O error
>>>>>> ===========================================
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Hardik
>>>>
>>>> "If you are doing what you have always been doing then expect what you
>>>> have always been getting."
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>>
>>
>> --
>> Regards,
>> Hardik
>>
>> "If you are doing what you have always been doing then expect what you
>> have always been getting."
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Regards,
> Hardik
>
> "If you are doing what you have always been doing then expect what you
> have always been getting."
>
>
>
>
>
>
>
>
--
Regards,
Hardik
"If you are doing what you have always been doing then expect what you
have always been getting."
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
