Micro SDHCs overheat: custom Nautilus file copy routine?

[notthatbob]

Hi forum.

I have a problem that has to do with overheating microSDHC cards.

I cannot drag-and-drop, nor send to, nor any GUI-based methods of copying to them, because the little things cannot handle sustained transfers; that is, they get ludicrously hot and slow way down. (like a couple k/sec slow, and sometimes never finish the write.) Not all of them do this. It's mostly the Class 6, 10, and the new speedy UHS-I microSDXCs... the ones that are supposed to be fast!

II've taken to sending the data over a slower method, using rsync and the --bwlimit switch. It works, and if I set the speed too high, I can break and resume at a lower speed once the card cools down.

I was also pondering how to emulate (for example) a camera; that is, burst over a few hundred megs at full speed, but implement a pause of ~10s or something before continuing. I would assume I could make it faster than a sustained transfer at a lower speed...

Another problem is that copying via GUI tends to try to simultaneously copy files; if I drag files here, then on another desktop drag more, it will do both - this just overheats the cards that much faster. I'd love a solution where the copies got queued, where it wouldn't let more than one file at a time, although an overall bandwidth limit would solve this problem too.

Still another problem is that, with my current solution, I either set all cards very low (ie. --bwlimit=2400) or have to test each and every card, card+SD adapter, card+MicroSDHC->USB adapter combination, and keep track of what scenarios can do what speed reliably.

I've already started to memorize what cards are "troublemakers" so I guess what would be needed is maybe udev rules, where I could use the data I've collected about said cards to attach a speed limit to it, that "follows it around" every mount? I don't know, I'm thinking aloud. I would prefer an automated way to either test the card and set it's speed limit, or a way to drop the transfer rate on-the-fly automatically, but I'm not holding my breath for this one.

I would love a GUI file copy solution.

I'm also looking into getting better adapters since the full-sized SDHC cards don't overheat anywhere near as often as the micro cards do, but haven't found any that are better than the ones that ship with the "kit" cards like Sandisk provides. Anyone seen a solid copper MicroSD adapter?

Thank you for reading my exceedingly long post.
Any thoughts or solutions greatly appreciated!

[rtguille]

Please try with more than one card reader, and check if it is
card reader dependant. (under the same OS/Kernel).

Then swich the OS (maybe some live-cd, like sysrescuecd) with
the problematic card reader - card combo.

Also, please post some hardware info, which card reader, machine
type (desktop/laptop).

# lsusb
# lspci -nn

Check if there are some errors or something in /var/log/messages when
the 'slowdown' takes place.

[mmmmm]

I have had a similar problem for about a year now.

Different micro SD(HC) cards behaving differently. Only on one computer, but it wasn't before about Fedora 14, so I suspected a software update. The cards always worked when connected to other computers. Different card readers made no difference. A solid metal box wasn't better than a tiny plug.

I found nothing about the problem on the web about this, except for this thread. It seemed to be time to look at it myself.

So I compared the USB traffic for tar-ring up a full SDHC card's content on different computers with Wireshark. Result: All computers sent out the same commands. On the 'broken' computer, the card (reader) failed to report a read command success after sending a data block successfully at some point between 1 and 2 gigabytes transferred. The LBA address was at about 1GB, so it cannot be an SDHC specific problem. After re-initialising the bus and assigning a new address to the reader, the reader did not come back with a valid configuration.

The micro SD card was quite hot in the small plastic (plug type) reader, so it might have consumed more than the 100 mA (<0.5W) that lsusb -v indicated. So I put a powered hub between the computer and the card reader. The tar command completed successfully.

Comparing the power situations on all my computers, I found that the 'broken' computer was the only one where all USB ports were shared with other bus powered devices on the same bus and no powered hub in between. (I didn't expect that. I thought that when testing through all free USB sockets, the power situation would be optimal at at least one port. I was wrong here. Otherwise I would have followed this road earlier.) All my other computers had no other bus powered USB equipment at all.

So think that your problem might be similar. Make sure that your USB card reader is either self-powered or is the only device behind a proper power supply and retry.

Good luck!