This bug is missing log files that will aid in diagnosing the problem.
While running an Ubuntu kernel (not a mainline or third-party kernel)
please enter the following command in a terminal window:
apport-collect 1839216
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
** Tags added: xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1839216
Title:
xenial VM hangs copying block device
Status in linux package in Ubuntu:
Incomplete
Bug description:
With a Xenial kernel running in a VM (32 cores and 65536 MB RAM), the
following script hangs in the dd command:
==================================================================================
#!/bin/bash
dd if=/dev/zero of=in.bin bs=1 seek=6442506751 count=1
cp in.bin out.bin
IN=$(losetup --show -f in.bin)
OUT=$(losetup --show -f out.bin)
typeset -i i=1
while true; do
echo $i $(date)
dd if=$IN of=$OUT bs=128k
i=i+1
done
==================================================================================
The trace (sorry, I don't have the exact kernel version... I found this
mid-June 2019) looks like:
# cat /proc/5230/stack
[<0>] io_schedule+0x16/0x40
[<0>] wbt_wait+0x234/0x390
[<0>] blk_mq_make_request+0x103/0x590
[<0>] generic_make_request+0x122/0x2f0
[<0>] submit_bio+0x73/0x150
[<0>] submit_bh_wbc+0x17a/0x1b0
[<0>] __block_write_full_page+0x15b/0x400
[<0>] block_write_full_page+0x10c/0x130
[<0>] blkdev_writepage+0x18/0x20
[<0>] __writepage+0x1d/0x50
[<0>] write_cache_pages+0x228/0x4b0
[<0>] generic_writepages+0x5c/0x90
[<0>] blkdev_writepages+0x2f/0x40
[<0>] do_writepages+0x1f/0x70
[<0>] __filemap_fdatawrite_range+0xc6/0x100
[<0>] filemap_write_and_wait+0x31/0x90
[<0>] __blkdev_put+0x7a/0x210
[<0>] blkdev_put+0x4c/0xd0
[<0>] blkdev_close+0x34/0x70
[<0>] __fput+0xea/0x220
[<0>] ____fput+0xe/0x10
[<0>] task_work_run+0x9a/0xc0
[<0>] exit_to_usermode_loop+0xce/0xd0
[<0>] do_syscall_64+0x116/0x150
[<0>] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[<0>] 0xffffffffffffffff
If we have used strace on the process, we find that dd is inside
"close(1)" as it closes the output file.
I don't know if this would reproduce on actual hardware, as I don't
have a machine that large to play with.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1839216/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
