Crashed dd, kill -9 doesn't even kill it.
Timothy Legg
I have got another interesting problem here. I found a way to crash dd so
badly that even kill -9 `pidof dd` won't even phase it. The only way I
have found to kill it effectively is to shut down the machine.
Scenario:
I bought a 2Gb MP3 player (GPX MW249BU). I always made a backup of any
flash device before I use it too heavily so that in the event that I break
the filesystem, I can restore it easily.
# dd if=/dev/sdb of=/media/disk-1/GPX.img bs=512
I know it is best form to use the 'count' parameter to identify a stopping
point for dd, but usually it reaches the end of the device and then stops
anyway. This is how it has done when I make periodic backups/restores of
my flash based netbook.
It created the 2Gb file and then hung. I have had this happen when I
attempted yesterday with the same device.
# kill `pidof dd`
and
# kill -9 `pidof dd`
does not phase it. I went into dmesg and found this going on. It looks
like it has been doing this all night. While certain lines may seem to
recur, each group of output seems unique.
This is just a small portion. To save you a very long e-mail, a much
longer (3.5Mb) version is posted on my website:
http://www.timothylegg.com/dd_usb_errors.txt
Any suggestions?
Tim Legg
[58003.536064] INFO: task usb-storage:6056 blocked for more than 120 seconds.
[58003.536074] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[58003.536079] usb-storage D f881f080 0 6056 2
[58003.536086] ef48f0c0 00000046 c180bfc0 f881f080 f7859800
ef48f24c c180bfc0 00000000
[58003.536096] cbe19c00 0062b598 f7859800 c180bfc0 00000000
00000000 00000000 000000ff
[58003.536104] 7fffffff 7fffffff f7e3feb8 00000002 c02b8ac9
7fffffff 7fffffff f7e3fecc
[58003.536113] Call Trace:
[58003.536188] [<c02b8ac9>] schedule_timeout+0x13/0x86
[58003.536218] [<c01081dc>] nommu_map_sg+0x5b/0x80
[58003.536228] [<c01081ef>] nommu_map_sg+0x6e/0x80
[58003.536247] [<c02b81ed>] wait_for_common+0xaf/0x10f
[58003.536260] [<c011b6fc>] default_wake_function+0x0/0x8
[58003.536284] [<f885f59a>] usb_sg_wait+0x101/0x118 [usbcore]
[58003.536330] [<f8c48d58>] usb_stor_bulk_transfer_sglist+0x6a/0xa3
[usb_storage]
[58003.536360] [<f8c48dfd>] usb_stor_bulk_srb+0x18/0x28 [usb_storage]
[58003.536390] [<f8c4913a>] usb_stor_Bulk_transport+0x102/0x23c
[usb_storage]
[58003.536430] [<f8c49289>] usb_stor_invoke_transport+0x15/0x1c0
[usb_storage]
[58003.536455] [<c0118cb7>] wakeup_preempt_entity+0x2e/0x45
[58003.536467] [<c011fdb9>] check_preempt_wakeup+0xa6/0xc6
[58003.536480] [<c02b91a3>] __down_interruptible+0x62/0x98
[58003.536516] [<f8c4982e>] usb_stor_control_thread+0xfe/0x19c [usb_storage]
[58003.536543] [<c011a646>] complete+0x28/0x36
[58003.536558] [<f8c49730>] usb_stor_control_thread+0x0/0x19c [usb_storage]
[58003.536572] [<c01318db>] kthread+0x38/0x5d
[58003.536579] [<c01318a3>] kthread+0x0/0x5d
[58003.536587] [<c01044f3>] kernel_thread_helper+0x7/0x10
[58003.536608] =======================
[58003.536612] INFO: task hald-addon-stor:6109 blocked for more than 120
seconds.
[58003.536615] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[58003.536618] hald-addon-st D f06dd8e4 0 6109 3079
[58003.536623] ef570d20 00000082 f8c07a34 f06dd8e4 000017ce
ef570eac c180bfc0 00000000
[58003.536632] ffffffff ffffffff 00067407 00000000 f7d8e750
f732a900 00001d4c 000000ff
[58003.536640] 7fffffff 7fffffff f7fadd2c 00000002 c02b8ac9
00000086 f7d8e750 f7d8e750
[58003.536649] Call Trace:
[58003.536659] [<f8c07a34>] scsi_get_cmd_from_req+0x1b/0x41 [scsi_mod]
[58003.536731] [<c02b8ac9>] schedule_timeout+0x13/0x86
[58003.536749] [<c01d0cf8>] elv_next_request+0xf7/0x18e
[58003.536770] [<f8c08bf9>] scsi_request_fn+0x2e6/0x32a [scsi_mod]
[58003.536799] [<c02b81ed>] wait_for_common+0xaf/0x10f
[58003.536812] [<c011b6fc>] default_wake_function+0x0/0x8
[58003.536832] [<c01d5190>] blk_execute_rq+0x83/0x96
[58003.536840] [<c01d51a3>] blk_end_sync_rq+0x0/0x25
[58003.536847] [<c0158cad>] mempool_alloc+0x1c/0xba
[58003.536860] [<c01dc273>] cfq_set_request+0x0/0x269
[58003.536873] [<c01d05e8>] elv_set_request+0x14/0x22
[58003.536884] [<c01d2a92>] get_request+0x1e5/0x2c7
[58003.536913] [<c01d3020>] get_request_wait+0x106/0x117
[58003.536948] [<f8c08011>] scsi_execute+0xc5/0x103 [scsi_mod]
[58003.536984] [<f8c080d3>] scsi_execute_req+0x84/0xa1 [scsi_mod]
[58003.537037] [<f8c0813b>] scsi_test_unit_ready+0x4b/0xa6 [scsi_mod]
[58003.537090] [<f8bff00b>] sd_media_changed+0xd0/0x171 [sd_mod]
[58003.537112] [<c01942f4>] check_disk_change+0x13/0x57
[58003.537126] [<f8bfe83f>] sd_open+0xce/0x152 [sd_mod]
[58003.537146] [<c0194a1f>] do_open+0x1cc/0x28d
[58003.537172] [<c0194c5b>] blkdev_open+0x0/0x4d
[58003.537177] [<c0194c80>] blkdev_open+0x25/0x4d
[58003.537190] [<c0172f87>] __dentry_open+0x10d/0x1fc
[58003.537211] [<c0173092>] nameidata_to_filp+0x1c/0x2c
[58003.537226] [<c017d7d3>] do_filp_open+0x34f/0x684
[58003.537246] [<c0153213>] handle_fasteoi_irq+0x9b/0xa4
[58003.537261] [<c0105f3f>] do_IRQ+0x52/0x63
[58003.537291] [<f8bfd9da>] scsi_disk_put+0x22/0x2e [sd_mod]
[58003.537304] [<f8bfea8b>] sd_release+0x99/0xa0 [sd_mod]
[58003.537342] [<c0172da4>] do_sys_open+0x40/0xb0
[58003.537362] [<c0172e58>] sys_open+0x1e/0x23
[58003.537377] [<c0103853>] sysenter_past_esp+0x78/0xb1
[58003.537428] =======================
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/b394841596f8775379ef...@www.timothylegg.com
Bob McGowan
> Hello,
>
> I have got another interesting problem here. I found a way to crash dd so
> badly that even kill -9 `pidof dd` won't even phase it. The only way I
> have found to kill it effectively is to shut down the machine.
<snipped>
> # dd if=/dev/sdb of=/media/disk-1/GPX.img bs=512
>
> I know it is best form to use the 'count' parameter to identify a stopping
> point for dd, but usually it reaches the end of the device and then stops
> anyway. This is how it has done when I make periodic backups/restores of
> my flash based netbook.
>
> It created the 2Gb file and then hung. I have had this happen when I
> attempted yesterday with the same device.
>
> # kill `pidof dd`
> and
> # kill -9 `pidof dd`
>
> does not phase it. I went into dmesg and found this going on. It looks
<snipped>
There are only two reasons I know of, where a 'kill -9' won't "work".
1. The process is a "zombie". This is not your situation, but
mentioned here for completeness. ;) There is no real process, the
program has exited, but something was supposed to wait for it. The
process slot is kept, so the 'wait' can be properly handled by the kernel.
2. Or, and I think this is your case: the process has called a kernel
service that is not interruptible (after all, you can't kill the kernel ;).
This appears to be related to the "usb-storage" and "hald-addon-stor"
modules (?) in the kernel, I think.
Regardless, the only "solution" for either of the above "hangs" is to
reboot, as you've discovered, though it might be possible to un-hang the
kernel code by pulling the USB device (though this may wreak havoc with
the contents).
I have a USB flash drive that causes me some problems with mounting
(nothing like what you saw, though I've never tried a 'dd' on it,
either) because the manufacturer did not create a partition table, but
rather uses the "whole" device for the file system (sdd is used rather
than sdd1).
I wonder if your device is partitioned or not, and if not, if that might
be the root cause of the hang?
I have no thoughts regarding fixing this, other than to suggest using a
different method to back it up, such as tar or cpio. If the device
'dies' and you need to rebuild it, you'd need to reformat as FAT32 or
whatever, and copy files back on (a two step process '-(
--
Bob McGowan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bill Thompson
"Timothy Legg" <debia...@timothylegg.com> wrote:
> Hello,
>
> I have got another interesting problem here. I found a way to crash
> dd so badly that even kill -9 `pidof dd` won't even phase it. The
> only way I have found to kill it effectively is to shut down the
> machine.
>
> Scenario:
>
<snippage>
I had the same thing happen recently. It is as if dd is hitting the end
of the device and then locking up instead of stopping gracefully. I was
able to duplicate the issue with several USB-sticks using both dd and
dd_rescue.
The solution was to tell dd where to stop coping the device. For a 1GB
memory stick I used "dd bs=1G count=1" or "dd_rescue -m 1G"
--
Bill Thompson
Bi...@Mahagonny.com