Skip to contentSkip to conversation

SDHC card affected by preemption model in 2.6.35

DISCUSSION Mathieu Poirier 4 participants 10 messages Jun 15, 2010 – Feb 20, 2011 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
Driver: mmci-omap-hs

I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY.

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away.

When booting, a failing card (PREEMPT_VOLUNTARY) will output the following:

[ 2.283355] mmc0: error -110 whilst initialising SD card

I have also seen transfer errors such as this one:

[ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr

26, card status 0xc00

When working properly (PREEMPT_NONE), you get:

[   27.026519] mmc0: new high speed SDHC card at address 0007
[   27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB 

We seem to have a little timing problem - has anyone seen the same issue ? Can driver "mmci-omap-hs" actually work under PREEMPT_VOLUNTARY ?

Thanks, Mathieu.

#1 lore raw
Quoted 23 lines · Mathieu Poirier

HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
Driver: mmci-omap-hs

I am faced with an SDHC card problem on a beagleboard.  Some cards cannot be initialized on startup while others work perfectly.  I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY.

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away.

When booting, a failing card (PREEMPT_VOLUNTARY) will output the following:

[ 2.283355] mmc0: error -110 whilst initialising SD card

I have also seen transfer errors such as this one:

[ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr

26, card status 0xc00

When working properly (PREEMPT_NONE), you get:
[   27.026519] mmc0: new high speed SDHC card at address 0007 [   27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB

Quoted 6 lines

We seem to have a little timing problem - has anyone seen the same issue ?  Can driver "mmci-omap-hs" actually work under PREEMPT_VOLUNTARY ?

Thanks, Mathieu.

I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful.

Thanks,
Venkat.
--
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

#2 lore raw
Quoted 31 lines · Venkatraman S
Quoted 20 lines · Mathieu Poirier

HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
Driver: mmci-omap-hs

I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY.

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away.

When booting, a failing card (PREEMPT_VOLUNTARY) will output the following:

[ 2.283355] mmc0: error -110 whilst initialising SD card

I have also seen transfer errors such as this one:

[ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr

26, card status 0xc00

When working properly (PREEMPT_NONE), you get:

Quoted 9 lines
[   27.026519] mmc0: new high speed SDHC card at address 0007
[   27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB

We seem to have a little timing problem - has anyone seen the same issue ? Can driver "mmci-omap-hs" actually work under PREEMPT_VOLUNTARY ?

Thanks, Mathieu.

Quoted 6 lines

I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful.

Thanks,
Venkat.

Venkat,

Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console.

As for the cards, had failures with 3 different manufacturer:
- Patriot Memory, MicroSD card, 8GB, class 4, SDHC.
- Kinston, 4GB, class 6, SDHC.
- Sandisk, 4GB, Class 2, SDHC.

I am more than willing to test kernels for you if need be.

Thanks, Mathieu.

#3 lore raw
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE

the problem goes away.

Have you found whether this is a problem
with the OMAP HSMMC driver
versus the MMC/SD framework code

#4 lore raw
Quoted 7 lines · David Brownell
Quoted 2 lines
Quoted 1 line
Quoted 1 line

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE

the problem goes away.

Have you found whether this is a problem
with the OMAP HSMMC driver
versus the MMC/SD framework code

Not yet - I'm in the code, investigating.

#5 lore raw
In reply to Mathieu Poirier
Quoted 45 lines · Mathieu Poirier
Quoted 31 lines · Venkatraman S
Quoted 23 lines · Mathieu Poirier

HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
Driver: mmci-omap-hs

I am faced with an SDHC card problem on a beagleboard.  Some cards cannot be initialized on startup while others work perfectly.  I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY.

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away.

When booting, a failing card (PREEMPT_VOLUNTARY) will output the following:

[ 2.283355] mmc0: error -110 whilst initialising SD card

I have also seen transfer errors such as this one:

[ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr

26, card status 0xc00

When working properly (PREEMPT_NONE), you get:
[   27.026519] mmc0: new high speed SDHC card at address 0007 [   27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB

Quoted 6 lines

We seem to have a little timing problem - has anyone seen the same issue ?  Can driver "mmci-omap-hs" actually work under PREEMPT_VOLUNTARY ?

Thanks, Mathieu.

Quoted 6 lines

I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful.

Thanks,
Venkat.

Venkat,

Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console.

Quoted 9 lines

As for the cards, had failures with 3 different manufacturer:
- Patriot Memory, MicroSD card, 8GB, class 4, SDHC.
- Kinston, 4GB, class 6, SDHC.
- Sandisk, 4GB, Class 2, SDHC.

I am more than willing to test kernels for you if need be.

Thanks, Mathieu.

For MMC/SD logs to be sent to the console, you need to
a) "echo 8 > /proc/sys/kernel/printk" in the shell and
b) insert the card

If you are booting from the card itself, then this won't work and DEBUG_LL has to be enabled (in addition to CONFIG_MMC_DEBUG)

Apologies - I should have explained this initially.

Regards,
Venkat.
--
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

#6 lore raw
Quoted 60 lines · Venkatraman S
Quoted 45 lines · Mathieu Poirier
Quoted 31 lines · Venkatraman S
Quoted 20 lines · Mathieu Poirier

HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
Driver: mmci-omap-hs

I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY.

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away.

When booting, a failing card (PREEMPT_VOLUNTARY) will output the following:

[ 2.283355] mmc0: error -110 whilst initialising SD card

I have also seen transfer errors such as this one:

[ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr

26, card status 0xc00

When working properly (PREEMPT_NONE), you get:

Quoted 9 lines
[   27.026519] mmc0: new high speed SDHC card at address 0007
[   27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB

We seem to have a little timing problem - has anyone seen the same issue ? Can driver "mmci-omap-hs" actually work under PREEMPT_VOLUNTARY ?

Thanks, Mathieu.

Quoted 6 lines

I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful.

Thanks,
Venkat.

Venkat,

Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console.

Quoted 9 lines

As for the cards, had failures with 3 different manufacturer:
- Patriot Memory, MicroSD card, 8GB, class 4, SDHC.
- Kinston, 4GB, class 6, SDHC.
- Sandisk, 4GB, Class 2, SDHC.

I am more than willing to test kernels for you if need be.

Thanks, Mathieu.

For MMC/SD logs to be sent to the console, you need to
a) "echo 8 > /proc/sys/kernel/printk" in the shell and
b) insert the card

Quoted 7 lines

If you are booting from the card itself, then this won't work and DEBUG_LL has to be enabled (in addition to CONFIG_MMC_DEBUG)

Apologies - I should have explained this initially.

Regards,
Venkat.

Venkat,

I am indeed booting from the card itself, making things more difficult. DEBUG_LL has been configured since the very beginning and still not much to look at on the console. To see something I had to pass loglevel=8 on the kernel command line. At that point there is tones of stuff coming out and the card is initialized properly, which points to a timing issue.

Since I couldn't reproduce the failure when debug messages are enabled, I turned them back off and started to instrument the code on the hunt for the failure.

I have cornered the source of the problem in "drivers/mmc/core/sd_ops.c", function "mmc_sd_switch". When the kernel is configured with PREEMPT_NONE, the value of "data.error" is set to "0" after "mmc_wait_for_req" returns. When PREEMPT_VOLUNTARY is configured, "data.error" gets set to "-110" upon "mmc_wait_for_req" returning, which prevent the remaining of the configuration to take place.

I am out of time for today but tomorrow I'll dive in "mmc_wait_for_req". Send me a line if the above rings a bell or you find something.

Ghorai, please find an answer to your question in the above trail.

Thanks, Mathieu.

#7 lore raw
Quoted 82 lines · Mathieu Poirier
Quoted 60 lines · Venkatraman S
Quoted 45 lines · Mathieu Poirier
Quoted 31 lines · Venkatraman S
Quoted 23 lines · Mathieu Poirier

HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
Driver: mmci-omap-hs

I am faced with an SDHC card problem on a beagleboard.  Some cards cannot be initialized on startup while others work perfectly.  I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY.

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away.

When booting, a failing card (PREEMPT_VOLUNTARY) will output the following:

[ 2.283355] mmc0: error -110 whilst initialising SD card

I have also seen transfer errors such as this one:

[ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr

26, card status 0xc00

When working properly (PREEMPT_NONE), you get:
[   27.026519] mmc0: new high speed SDHC card at address 0007 [   27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB

Quoted 6 lines

We seem to have a little timing problem - has anyone seen the same issue ?  Can driver "mmci-omap-hs" actually work under PREEMPT_VOLUNTARY ?

Thanks, Mathieu.

Quoted 6 lines

I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful.

Thanks,
Venkat.

Venkat,

Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console.

Quoted 9 lines

As for the cards, had failures with 3 different manufacturer:
- Patriot Memory, MicroSD card, 8GB, class 4, SDHC.
- Kinston, 4GB, class 6, SDHC.
- Sandisk, 4GB, Class 2, SDHC.

I am more than willing to test kernels for you if need be.

Thanks, Mathieu.

For MMC/SD logs to be sent to the console, you need to
a) "echo 8 > /proc/sys/kernel/printk" in the shell and
b) insert the card

Quoted 7 lines

If you are booting from the card itself, then this won't work and DEBUG_LL has to be enabled (in addition to CONFIG_MMC_DEBUG)

Apologies - I should have explained this initially.

Regards,
Venkat.

Venkat,

I am indeed booting from the card itself, making things more difficult. DEBUG_LL has been configured since the very beginning and still not much to look at on the console.  To see something I had to pass loglevel=8 on the kernel command line.  At that point there is tones of stuff coming out and the card is initialized properly, which points to a timing issue.

Since I couldn't reproduce the failure when debug messages are enabled, I turned them back off and started to instrument the code on the hunt for the failure.

Quoted 7 lines

I have cornered the source of the problem in "drivers/mmc/core/sd_ops.c", function "mmc_sd_switch".  When the kernel is configured with PREEMPT_NONE, the value of "data.error" is set to "0" after "mmc_wait_for_req" returns.  When PREEMPT_VOLUNTARY is configured, "data.error" gets set to "-110" upon "mmc_wait_for_req" returning, which prevent the remaining of the configuration to take place.

-110 = -ETIMEDOUT.
The error is set from omap_hsmmc.c line 1029, when the controller returns a DATA_TIMEOUT error.
This can happen for any mmc_wait_for_req() call, not just in mmc_sd_switch().

A simple workaround is to increase the timeout value, as below. Could you please try with this patch ?
Yes, it's a debugging hack and not the right solution.
[I have so far not reproduced the problem with my setup. Still trying..]

----

drivers/mmc/host/omap_hsmmc.c +0 -0
index b032828..9ca399e 100644
@@ -1413,7 +1413,7 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host

*host, struct mmc_request *req)

        OMAP_HSMMC_WRITE(host->base, BLK, (req->data->blksz)
                                        | (req->data->blocks << 16));

- set_data_timeout(host, req->data->timeout_ns, req->data->timeout_clks);
+ set_data_timeout(host, 100000000U, 0);

        if (host->use_dma) {
                ret = omap_hsmmc_start_dma_transfer(host, req);

----

This provides a good 100ms window for delays due to scheduling variations.
I have to still find out which section is sensitive to it. Regards,
Venkat.
--
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

#8 lore raw

Hello Mathieu, hello Venkat,

I hope it is not too old and you remember this:

Am 17.06.2010 16:33, schrieb Venkatraman S:

Quoted 116 lines
Quoted 82 lines · Mathieu Poirier
Quoted 60 lines · Venkatraman S
Quoted 45 lines · Mathieu Poirier
Quoted 31 lines · Venkatraman S
Quoted 20 lines · Mathieu Poirier

HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
Driver: mmci-omap-hs

I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY.

When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away.

When booting, a failing card (PREEMPT_VOLUNTARY) will output the following:

[ 2.283355] mmc0: error -110 whilst initialising SD card

I have also seen transfer errors such as this one:

[ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr

26, card status 0xc00

When working properly (PREEMPT_NONE), you get:

Quoted 9 lines
[   27.026519] mmc0: new high speed SDHC card at address 0007
[   27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB

We seem to have a little timing problem - has anyone seen the same issue ? Can driver "mmci-omap-hs" actually work under PREEMPT_VOLUNTARY ?

Thanks, Mathieu.

Quoted 6 lines

I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful.

Thanks,
Venkat.

Venkat,

Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console.

Quoted 9 lines

As for the cards, had failures with 3 different manufacturer:
- Patriot Memory, MicroSD card, 8GB, class 4, SDHC.
- Kinston, 4GB, class 6, SDHC.
- Sandisk, 4GB, Class 2, SDHC.

I am more than willing to test kernels for you if need be.

Thanks, Mathieu.

For MMC/SD logs to be sent to the console, you need to
a) "echo 8 > /proc/sys/kernel/printk" in the shell and
b) insert the card

Quoted 7 lines

If you are booting from the card itself, then this won't work and DEBUG_LL has to be enabled (in addition to CONFIG_MMC_DEBUG)

Apologies - I should have explained this initially.

Regards,
Venkat.

Venkat,

I am indeed booting from the card itself, making things more difficult. DEBUG_LL has been configured since the very beginning and still not much to look at on the console. To see something I had to pass loglevel=8 on the kernel command line. At that point there is tones of stuff coming out and the card is initialized properly, which points to a timing issue.

Since I couldn't reproduce the failure when debug messages are enabled, I turned them back off and started to instrument the code on the hunt for the failure.

Quoted 7 lines

I have cornered the source of the problem in "drivers/mmc/core/sd_ops.c", function "mmc_sd_switch". When the kernel is configured with PREEMPT_NONE, the value of "data.error" is set to "0" after "mmc_wait_for_req" returns. When PREEMPT_VOLUNTARY is configured, "data.error" gets set to "-110" upon "mmc_wait_for_req" returning, which prevent the remaining of the configuration to take place.

-110 = -ETIMEDOUT.
The error is set from omap_hsmmc.c line 1029, when the controller returns a DATA_TIMEOUT error.
This can happen for any mmc_wait_for_req() call, not just in mmc_sd_switch().

A simple workaround is to increase the timeout value, as below. Could you please try with this patch ?
Yes, it's a debugging hack and not the right solution.
[I have so far not reproduced the problem with my setup. Still trying..]

----

drivers/mmc/host/omap_hsmmc.c +1 -1
index b032828..9ca399e 100644
@@ -1413,7 +1413,7 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host
 *host, struct mmc_request *req)
 
        OMAP_HSMMC_WRITE(host->base, BLK, (req->data->blksz)
                                        | (req->data->blocks << 16));
-       set_data_timeout(host, req->data->timeout_ns, req->data->timeout_clks);
+       set_data_timeout(host, 100000000U, 0);
 
        if (host->use_dma) {
                ret = omap_hsmmc_start_dma_transfer(host, req);
Quoted 7 lines

----

This provides a good 100ms window for delays due to scheduling variations.
I have to still find out which section is sensitive to it. Regards,
Venkat.
--

We have a custom omap3 board and use kernel 2.6.37-rc8. We have the problem that we sometimes cannot mount our rootfs from sd-card. This happens only when CONFIG_PREEMPT=y. When using CONFIG_PREEMPT_NONE or enabling CONFIG_MMC_DEBUG everything works fine.

The "100 ms patch" doesn't work for us. Do you found other solution(s)?

Regards,
Thomas

A message that is not in the archive (sent off-list or not yet received): [email protected]

#10 lore raw
Quoted 13 lines · Venkatraman
Quoted 11 lines · Thomas Weber

Hello Mathieu, hello Venkat,

I hope it is not too old and you remember this:

Quoted 6 lines

  This provides a good 100ms window for delays due to scheduling variations. I have to still find out which section is sensitive to it. Regards,
Venkat.
--

Quoted 7 lines
Quoted 7 lines

We have a custom omap3 board and use kernel 2.6.37-rc8.  We have the problem that we sometimes cannot mount our rootfs from sd-card. This happens only when CONFIG_PREEMPT=y. When using CONFIG_PREEMPT_NONE or enabling CONFIG_MMC_DEBUG everything works fine.

The "100 ms patch" doesn't work for us. Do you found other solution(s)?

No - I was working on some other things lately - I'll check this out this week. What type of card are you using ?
Regards,
Venkat.
--
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