mmcblk0: error -84 transferring data

[MrConfusion]

Hello,

After the expected initial setup hassle, a few months went by without any issues (what an understatement, this thing is hands down the best PDA I ever had...).

During these months (mostly due to being busy at work :-( ) there have been no changes to my setup. Basically I'm running kernel 3.2.52 in SL4P14.0.

Yet "under the radar" these messages started appearing and seem to get more and more frequent, now they are getting "impossible to ignore" as they pretty much flood dmesg output:

mmcblk0: error -84 transferring data, sector XXX, nr 128, cmd response 0x900, card status 0x0

or same error, but card status 0xb00

It then says:

mmcblk0: retrying using single block read

And no further errors for that sector --> it seems to "recover" from the problem with this single block read?

So, right, I figured the card in mmcblk0 is going bad, no big deal... Well, I still hope that is the case (cheap and easy fix...) but before I rush to buy a new one, I decided to test a bit and now I'm not so sure whether I should get a new card anymore...

Cards check out OK in a Linux PC and they also check out OK in the Pandora itself: no data loss that I can see, my main ext4 (nonjournaled) partition goes through fsck at every boot. Despite a flood of these messages fsck does not complain at all.

And indeed, when I switch my cards (both are 32GB SanDisk Extreme Class 10) between slots mmcblk0 and mmcblk1 errors still appear in mmcblk0, but not in mmcblk1!

So it definitely seems that the cards are not the problem, it's in the reader...?

(I also verified that mmcblk0 and mmcblk1 device IDs stay consistent: the two SanDisk Extremes have different disk IDs (when viewed through fdisk).)

It really seems to me now that mmcblk1 is not affected. Since I run software RAID the logs would tell me reliably enough. But no: all the errors come from mmcblk0.

Has anyone come across something like this before?

I could not find the exact same symptom from previous posts, some Googling gave me hits about similar messages from other devices, but nothing conclusive. A timing issue for SD card driver was mentioned, but I could not find details for fixing it.

So, all in all: it only seems to affect the speed of mmcblk0 (i.e. it doesn't corrupt data) and only "left slot" is affected.

Ideas?

So far the only thing I've tried is taking the battery out for a night just in case... well, no help from that.

For now I don't really mind if I need to switch mmcblk0 to a slower transfer mode (something like DMA vs. PIO in a PC), if that is doable and "solves" the problem: I'd like to get rid of the messages.

Optimally, of course, I'd like to have the card reader running at full speed too...

 

[notaz]

Sounds like a CC pandora? That model has OMAP3 ES2.1 revision with bugged SD controller, multiblock transfers fail there due to some timing issue in hardware. Only left slot is affected because the right one has a transceiver chip attached, and that avoids the issue as the chip supplies the clock.

Mainline kernel has multiblock transfers disabled completely for ES2.1, but that makes it crawl, like order of magnitude slower, also some cards refuse to work completely without multiblock transfers. Because of that I've added some hacks in the kernel to still do multiblock transfers but do them on slower clock and feed the data in smaller chunks. This reduces the problem significantly, but errors still happen occasionally, like you're seeing.

There is a way to disable my hack, try writing 0 to this file:

/sys/devices/platform/omap_hsmmc.0/mmc_host/mmc0/unsafe_read

 

[MrConfusion]

OK, thank you a lot, this clarified things. And yes, it is a CC unit.

Since this is a known issue and since (like I mentioned above) there is apparently no (or at least "practically no") risk of data loss, I consider this a non-issue .

Instead of disabling the hack, I'll try to make a change in logging, because dmesg still gets a bit more clobbered than I'd prefer.

 

[ibisum]

Funny times .. I came to this thread because one of my rPi's is now reporting this -84 error on its SD card .. and now I hear from notaz the details about such things.