SDHC card affected by preemption model in 2.6.35
Hello Venkat, Hello Mathieu,
Quoted 5 lines
No. I was working on some other things lately. What card are you using and how often are you seeing this ?
Regards,
Venkat.
We get the timeout Problem every time:
[ 1.888732] Waiting for root device /dev/mmcblk0p2... [ 4.193603] mmc0: error -110 whilst initialising SD card
Right now the issue occurs with following cards CONFIG_PREEMPT=y enabled:
- SanDisk 4GB micro SDHC Class 2
- SanDisk 2GB micro SD
These cards worked fine:
- Transcend 2GB micro SD
- Transcend 4GB micro SDHC Class 6
- SanDisk 4GB micro SDHC Class 6 (Mobile Ultra)
Thanks,
Johannes
Hi guys,
Quoted 6 lines · Johannes Reif
Hello Venkat, Hello Mathieu,
Quoted 4 lines
No. I was working on some other things lately. What card are you using and
how often are you seeing this ?
Quoted 8 lines
Quoted 2 lines
Regards,
Venkat.We get the timeout Problem every time:
[ 1.888732] Waiting for root device/dev/mmcblk0p2... [ 4.193603] mmc0: error -110 whilst initialising SD cardRight now the issue occurs with following cards
CONFIG_PREEMPT=yenabled:
There is a bug in the kernel workqueues. I observed it in 2.6.36.3 (it seems to have been introduced in 2.6.36 and is still in 2.6.37.1), One of my colleagues was investigating and contacted the author of the workqueue code (Tejun Heo). Tejun sent us the following patch:
kernel/workqueue.c +9 -0
@@ -2047,6 +2047,15 @@ repeat:move_linked_works (work, scheduled, &n);process_scheduled_works (rescuer); + +/* +* Leave this gcwq. If keep_working() is %true, notify a +* regular worker; otherwise, we end up with 0 concurrency +* and stalling the execution. +*/ +if (keep_working (gcwq)) +wake_up_worker (gcwq); +spin_unlock_irq (&gcwq->lock); }
For us, this was causing card insertion events to not be processed. For us it was a race condition and depended on when the timer tick occured in relation to other processing, and since you're talking about PREEMPTION making a difference, I thought I would throw this out as maybe being relevant.
Dave Hylands
--
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
Hi all,
Quoted 28 lines · Dave Hylands
Hi guys,
There is a bug in the kernel workqueues. I observed it in 2.6.36.3 (it seems to have been introduced in 2.6.36 and is still in 2.6.37.1), One of my colleagues was investigating and contacted the author of the workqueue code (Tejun Heo). Tejun sent us the following patch:
kernel/workqueue.c +9
-0@@ -2047,6 +2047,15 @@ repeat:move_linked_works (work, scheduled,&n);process_scheduled_works (rescuer); + +/* +* Leave this gcwq. If keep_working() is %true, notify a +* regular worker; otherwise, we end up with 0 concurrency +* and stalling the execution. +*/ +if (keep_working (gcwq)) +wake_up_worker (gcwq); +spin_unlock_irq (&gcwq->lock); }
Quoted 7 lines
For us, this was causing card insertion events to not be processed. For us it was a race condition and depended on when the timer tick occured in relation to other processing, and since you're talking about PREEMPTION making a difference, I thought I would throw this out as maybe being relevant.
Dave Hylands
unfortunately the cards didn't work with the patch.
We tried updating from 2.6.37-rc8 to 2.6.38-rc5 and the timeout error still occurs. However the cards get detected after the error and seem to work fine:
[ 2.456512] Waiting for root device /dev/mmcblk0p2... [ 4.803375] mmc0: error -110 whilst initialising SD card [ 5.201019] mmc0: new SD card at address aaaa [ 5.206665] mmcblk0: mmc0:aaaa SU02G 1.84 GiB [ 5.214477] mmcblk0: p1 p2
Regards,
Johannes