dd writing to an SDHC /dev/mmcblk0

Bug #975305 reported by Michael Cook
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Medium
Unassigned

Bug Description

U12.04 beta 2 on 64-bit T420 Laptop.

Command 1: sudo dd if=./mmcblk0p1.bin of=/dev/mmcblk0p1 bs=10M
Command 2: sudo dd if=./mmcblk0.bin of=/dev/mmcblk0 bs=10M

Either command seems to hang, not start copying anything to /dev/mmcblk0.
The dd command copies from the SDHC at 10Mbps.
(Could not test in 10.10,11.10 as SDHC cards were not recognised by the system.)

Should this work, is the command issue missing a parameter or is there another way to clone an SDHC.

Other guides online seem to reference /dev/sd* but the device is not appearing like this, instead it appears as /dev/mmc* which is mountable and usable once mounted.

Tags: precise
affects: ubuntu → nautilus (Ubuntu)
tags: added: precise
Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Please give us some more information; can you include:

   1) The output of the dmesg command after you've issued one of these dd commands and waited
a few seconds?
   2) Information on the make/model/capacity of the SD card you are using.

I think the command should work, however be aware that SD cards are often much slower writing than reading (and can be quite fussy).

Also, make sure that the SD card is not mounted at the time that you issue these commands; finally if you do command (2) that will change your partition on the SD card, and if you've done that it's probably a good idea to take it out and put it back in afterwards before doing command 1 to make sure the kernel notices.

Generally USB sdcard readers appear as /dev/sd* hence the probable reason some of the examples say that.

affects: nautilus (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: New → Opinion
Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Sorry, I meant to set that to Incomplete.

Changed in linux (Ubuntu):
status: Opinion → Incomplete
Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

Thanks for the responses to date.

Needless to say, since opening this bug writing to the SDHC has started to work. Not sure why/how. I did format it once as FAT32 via gparted since opening this bug, previously, it was formatted as per the Canon camera (FAT32 also). However, I'm still seeing some issues I will report on my progress shortly.

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

1) The output of the dmesg command after you've issued one of these dd commands and waited
a few seconds?

If freshly formatted, it presents itself, mounted with the following dmesg:

[45841.715089] mmc0: card 0002 removed
[45847.861632] mmc0: new SDHC card at address 0003
[45847.862012] mmcblk0: mmc0:0003 SD16G 14.8 GiB
[45847.863443] mmcblk0: p1

I too was surprised to see it mounted as mccblk0 device and not a /dev/sd*.

- sudo dd if=./mmcblk0p1.bin of=/dev/mmcblk0p1 bs=10M
- Sometimes, after about 400 KB no more data is written to the device.
- Then dd seems to be uninterruptable unless I issue kill -9

It stays like this until I end the process with ejecting the card or killing dd.

2) Information on the make/model/capacity of the SD card you are using.

Its a 16Gb Kingston class 6 SDHC inserted directly into the card reader of the T420.
- Reading from the card, formatting and writing files to it works approximatley 10-20Mbps.
- Formatting it FAT32 works ok and has been used in canon cameras.
- Using it as a truecrypt partition also works fine, reading and writing is quite respectable.
- Reading using dd works at around 10Mbps.

Oddly enough, while writing up these notes, I formatted the SDHC with gparted. And now, instead of hanging around 400KB written it continues to copy almost all of the 14.8GiB. But right at the end has failed with an error message - insufficient disk space. Which is odd, because the image was taken from an exact same SDHC card make and model. It seems it failed very close to the end of the device memory at 14.8GiB.

sudo dd if=./mmcblk0.bin of=/dev/mmcblk0 bs=1024
dd: writing `/dev/mmcblk0': No space left on device

If I wish to clone an entire SDHC card, should I dd the device or just the partition? That is: mmcblk0 or mmcblk0p1? Is it necessary to format the SDHC first? I would not think so, but thought I'd ask.

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

It seems, dd is still attempting to write out, even though its complained of being out of disk space.
The kernel msgs are full of this:

[ 7902.830935] INFO: task blkid:25921 blocked for more than 120 seconds.
[ 7902.830937] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7902.830948] blkid D ffffffff81806240 0 25921 541 0x00000004
[ 7902.830951] ffff8801b272bb18 0000000000000082 ffff88023e5fbe00 ffffffffa052a100
[ 7902.830968] ffff8801b272bfd8 ffff8801b272bfd8 ffff8801b272bfd8 0000000000013780
[ 7902.830989] ffffffff81c0d020 ffff88022b8496f0 000000000b300000 ffff88022d602a58
[ 7902.830998] Call Trace:
[ 7902.831006] [<ffffffff8165a0df>] schedule+0x3f/0x60
[ 7902.831026] [<ffffffff8165aee7>] __mutex_lock_slowpath+0xd7/0x150
[ 7902.831034] [<ffffffff812f9120>] ? disk_map_sector_rcu+0x80/0x80
[ 7902.831042] [<ffffffff8165aafa>] mutex_lock+0x2a/0x50
[ 7902.831062] [<ffffffff811b01db>] __blkdev_get+0x7b/0x460
[ 7902.831069] [<ffffffff811b061e>] blkdev_get+0x5e/0x1e0
[ 7902.831077] [<ffffffff811b07fd>] blkdev_open+0x5d/0x80
[ 7902.831098] [<ffffffff81175a50>] __dentry_open+0x290/0x360
[ 7902.831105] [<ffffffff811b07a0>] ? blkdev_get+0x1e0/0x1e0
[ 7902.831114] [<ffffffff8129c3dc>] ? security_inode_permission+0x1c/0x30
[ 7902.831135] [<ffffffff8118369a>] ? inode_permission+0x4a/0x110
[ 7902.831141] [<ffffffff811760cd>] vfs_open+0x3d/0x40
[ 7902.831148] [<ffffffff81176fa0>] nameidata_to_filp+0x40/0x50
[ 7902.831167] [<ffffffff81185ed8>] do_last+0x3f8/0x730
[ 7902.831174] [<ffffffff811875b1>] path_openat+0xd1/0x3f0
[ 7902.831181] [<ffffffff8113b189>] ? __pte_alloc+0xa9/0x160
[ 7902.831201] [<ffffffff811879f2>] do_filp_open+0x42/0xa0
[ 7902.831211] [<ffffffff81318861>] ? strncpy_from_user+0x31/0x40
[ 7902.831218] [<ffffffff81182d3a>] ? do_getname+0x10a/0x180
[ 7902.831237] [<ffffffff8165bfee>] ? _raw_spin_lock+0xe/0x20
[ 7902.831244] [<ffffffff81194c97>] ? alloc_fd+0xf7/0x150
[ 7902.831251] [<ffffffff8117709d>] do_sys_open+0xed/0x220
[ 7902.831271] [<ffffffff811771f0>] sys_open+0x20/0x30
[ 7902.831277] [<ffffffff81664602>] system_call_fastpath+0x16/0x1b

Nothing stops this unless I kill 'dd' or eject the card.

Then there is a mess as it fails to write...

..
..
..
[ 8877.239519] end_request: I/O error, dev mmcblk0, sector 30337016
[ 8877.239523] end_request: I/O error, dev mmcblk0, sector 30337024
[ 8877.239528] end_request: I/O error, dev mmcblk0, sector 30337032
[ 8877.239562] mmcblk0: error -123 sending status command, retrying
[ 8877.239577] mmcblk0: error -123 sending status command, retrying
[ 8877.239592] mmcblk0: error -123 sending status command, aborting
[ 8877.239593] end_request: I/O error, dev mmcblk0, sector 30337040

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Hi Michael,
  Thanks for the info; lets see if I can answer some of the questions:

To clone a card the challenge is that any 2 cards aren't necessarily the same length - any 2 8GB cards might vary depending on the cards ideas of how much space to leave for bad sectors, how they organise thing and the general phase of the moon.

If you have really absolutely identical cards then cloning them using the whole device (/dev/mmcblk0) should work,
but if you want to clone so you could stuff it onto another one then the only safe way is to make sure the partition
is a bit smaller than the whole disk (to allow for the next card to be a bit smaller), then when you partition the new card
make the partition on the new one exactly the same size and then clone the partition.

Now, to your errors:
  1) well it shouldn't hard hang
   2) and if the card really is large enough for your image then it shouldn't run out of space - check that the size shown in /proc/partitions matches the size of your file.
  3) You shouldn't get that task hung error
   4) If you're getting any I/O error's prior to ejecting the card then the bit to include in this log is the set of stuff just before the first I/O error. Errors after ejecting the card are well, expected!

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Michael, does this still happen for you on the release 12.04 - if it does please reopen this bug.

Dave

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :
Download full text (34.2 KiB)

Yes, the laptop internal SDHC card reader appears to not work reliably. I can read photos off of the card and seem to have no problems. However, using dd I have problems. Today, I've tried to create a raspberry pi wheezy SD card with dd on U12.04.2 with all the latest patches as of today.

I get very similar behaviour. The dd of 2Gb image finishes in about 20secs and dmesg is full of errors. No hanging this time. It's written ~320Kb and exited.

This is the command I ran as per instructions on RaspPi website:

sudo dd bs=4M if=./2013-02-09-wheezy-raspbian.img of=/dev/mmcblk0

Note, mmcblk0 is the name of the card when using the internal reader. It appears as /dev/sdd when using a USB SDHC reader (see below) and doesn't have a problem writing using dd.

This is some of the dmesg output when writing to the mmcblk0 device:

[104169.104548] mmcblk0: error -123 sending status command, retrying
[104169.104565] mmcblk0: error -123 sending status command, retrying
[104169.104582] mmcblk0: error -123 sending status command, aborting
[104169.104583] end_request: I/O error, dev mmcblk0, sector 3467056
[104169.104587] end_request: I/O error, dev mmcblk0, sector 3467064
[104169.104590] end_request: I/O error, dev mmcblk0, sector 3467072
[104169.104594] end_request: I/O error, dev mmcblk0, sector 3467080
[104169.104598] end_request: I/O error, dev mmcblk0, sector 3467088
[104169.104601] end_request: I/O error, dev mmcblk0, sector 3467096
[104169.104605] end_request: I/O error, dev mmcblk0, sector 3467104
[104169.104610] end_request: I/O error, dev mmcblk0, sector 3467112
[104169.104615] end_request: I/O error, dev mmcblk0, sector 3467120
[104169.104620] end_request: I/O error, dev mmcblk0, sector 3467128
[104169.104625] end_request: I/O error, dev mmcblk0, sector 3467136
[104169.104630] end_request: I/O error, dev mmcblk0, sector 3467144
[104169.104685] mmcblk0: error -123 sending status command, retrying
[104169.104702] mmcblk0: error -123 sending status command, retrying
[104169.104719] mmcblk0: error -123 sending status command, aborting
[104169.104721] end_request: I/O error, dev mmcblk0, sector 3467152
[104169.104726] end_request: I/O error, dev mmcblk0, sector 3467160
[104169.104731] end_request: I/O error, dev mmcblk0, sector 3467168
[104169.104735] end_request: I/O error, dev mmcblk0, sector 3467176
[104169.104739] end_request: I/O error, dev mmcblk0, sector 3467184
[104169.104743] end_request: I/O error, dev mmcblk0, sector 3467192
[104169.104746] end_request: I/O error, dev mmcblk0, sector 3467200
[104169.104750] end_request: I/O error, dev mmcblk0, sector 3467208
[104169.104753] end_request: I/O error, dev mmcblk0, sector 3467216
[104169.104757] end_request: I/O error, dev mmcblk0, sector 3467224
[104169.104761] end_request: I/O error, dev mmcblk0, sector 3467232
[104169.104763] end_request: I/O error, dev mmcblk0, sector 3467240
[104169.104767] end_request: I/O error, dev mmcblk0, sector 3467248
[104169.104770] end_request: I/O error, dev mmcblk0, sector 3467256
[104169.104775] end_request: I/O error, dev mmcblk0, sector 3467264
[104169.104778] end_request: I/O error, dev mmcblk0, sector 3467272
[104169.104831] mmcblk0: error -123 sendin...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.