Ubuntu
linux package

task systemd-udevd:1906 blocked for more than 120 seconds.

Bug #1292400 reported by Jan Henke on 2014-03-14

This bug affects 15 people

	Status	Importance	Assigned to
linux (Ubuntu)	Expired	Medium	Unassigned
Trusty	Expired	Medium	Unassigned
Vivid	Expired	Medium	Unassigned

Bug Description

System log shows repeated incidents of "task systemd-udevd:1906 blocked for more than 120 seconds."

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-17-generic 3.13.0-17.37 [modified: boot/vmlinuz-3.13.0-17-generic]
ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
Uname: Linux 3.13.0-17-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CurrentDesktop: XFCE
Date: Fri Mar 14 08:54:36 2014
HibernationDevice: RESUME=UUID=0d223c65-8c7e-41b4-95b3-05b22ff4679b
InstallationDate: Installed on 2014-03-12 (1 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140312)
IwConfig:
eth0 no wireless extensions.

lo no wireless extensions.
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MachineType: Microsoft Corporation Virtual Machine
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-17-generic.efi.signed root=UUID=61b52c1b-300d-4c30-8966-db1745f4a4bc ro video:hyperv_fb=1920x1080 quiet splash vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-3.13.0-17-generic N/A
linux-backports-modules-3.13.0-17-generic N/A
linux-firmware 1.126
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/26/2012
dmi.bios.vendor: Microsoft Corporation
dmi.bios.version: Hyper-V UEFI Release v1.0
dmi.board.asset.tag: None
dmi.board.name: Virtual Machine
dmi.board.vendor: Microsoft Corporation
dmi.board.version: Hyper-V UEFI Release v1.0
dmi.chassis.asset.tag: 6485-6574-9248-6162-4701-6267-50
dmi.chassis.type: 3
dmi.chassis.vendor: Microsoft Corporation
dmi.chassis.version: Hyper-V UEFI Release v1.0
dmi.modalias: dmi:bvnMicrosoftCorporation:bvrHyper-VUEFIReleasev1.0:bd11/26/2012:svnMicrosoftCorporation:pnVirtualMachine:pvrHyper-VUEFIReleasev1.0:rvnMicrosoftCorporation:rnVirtualMachine:rvrHyper-VUEFIReleasev1.0:cvnMicrosoftCorporation:ct3:cvrHyper-VUEFIReleasev1.0:
dmi.product.name: Virtual Machine
dmi.product.version: Hyper-V UEFI Release v1.0
dmi.sys.vendor: Microsoft Corporation
---
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CurrentDesktop: XFCE
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=0d223c65-8c7e-41b4-95b3-05b22ff4679b
InstallationDate: Installed on 2014-03-12 (1 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140312)
IwConfig:
eth0 no wireless extensions.

lo no wireless extensions.
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MachineType: Microsoft Corporation Virtual Machine
Package: linux (not installed)
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-17-generic.efi.signed root=UUID=61b52c1b-300d-4c30-8966-db1745f4a4bc ro video:hyperv_fb=1920x1080 quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
RelatedPackageVersions:
linux-restricted-modules-3.13.0-17-generic N/A
linux-backports-modules-3.13.0-17-generic N/A
linux-firmware 1.126
RfKill:

Tags: trusty
Uname: Linux 3.13.0-17-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 11/26/2012
dmi.bios.vendor: Microsoft Corporation
dmi.bios.version: Hyper-V UEFI Release v1.0
dmi.board.asset.tag: None
dmi.board.name: Virtual Machine
dmi.board.vendor: Microsoft Corporation
dmi.board.version: Hyper-V UEFI Release v1.0
dmi.chassis.asset.tag: 6485-6574-9248-6162-4701-6267-50
dmi.chassis.type: 3
dmi.chassis.vendor: Microsoft Corporation
dmi.chassis.version: Hyper-V UEFI Release v1.0
dmi.modalias: dmi:bvnMicrosoftCorporation:bvrHyper-VUEFIReleasev1.0:bd11/26/2012:svnMicrosoftCorporation:pnVirtualMachine:pvrHyper-VUEFIReleasev1.0:rvnMicrosoftCorporation:rnVirtualMachine:rvrHyper-VUEFIReleasev1.0:cvnMicrosoftCorporation:ct3:cvrHyper-VUEFIReleasev1.0:
dmi.product.name: Virtual Machine
dmi.product.version: Hyper-V UEFI Release v1.0
dmi.sys.vendor: Microsoft Corporation

See original description

Tags:

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14:

AlsaInfo.txt Edit (3.1 KiB, text/plain; charset="utf-8")
BootDmesg.txt Edit (40.0 KiB, text/plain; charset="utf-8")
CRDA.txt Edit (322 bytes, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (18.0 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (2.7 KiB, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (1.3 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (103 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (901 bytes, text/plain; charset="utf-8")
ProcModules.txt Edit (946 bytes, text/plain; charset="utf-8")
PulseList.txt Edit (9.8 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (63.0 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (146.6 KiB, text/plain; charset="utf-8")
WifiSyslog.txt Edit (276.2 KiB, text/plain; charset="utf-8")

Revision history for this message

Brad Figg (brad-figg) wrote on 2014-03-14: Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1292400

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

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: AlsaInfo.txt

AlsaInfo.txt Edit (3.1 KiB, text/plain)

apport information

tags:	added: apport-collected
description:	updated

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: BootDmesg.txt

BootDmesg.txt Edit (40.0 KiB, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: CRDA.txt

CRDA.txt Edit (257 bytes, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: CurrentDmesg.txt

CurrentDmesg.txt Edit (18.7 KiB, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: ProcCpuinfo.txt

ProcCpuinfo.txt Edit (1.3 KiB, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: ProcEnviron.txt

ProcEnviron.txt Edit (103 bytes, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: ProcInterrupts.txt

ProcInterrupts.txt Edit (901 bytes, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: ProcModules.txt

#10

ProcModules.txt Edit (990 bytes, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: PulseList.txt

#11

PulseList.txt Edit (9.8 KiB, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: UdevDb.txt

#12

UdevDb.txt Edit (63.1 KiB, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: UdevLog.txt

#13

UdevLog.txt Edit (146.6 KiB, text/plain)

apport information

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-14: WifiSyslog.txt

#14

WifiSyslog.txt Edit (277.2 KiB, text/plain)

apport information

Jan Henke (jhe) on 2014-03-14

Changed in linux (Ubuntu):
status:	Incomplete → Confirmed

Revision history for this message

Andy Whitcroft (apw) wrote on 2014-03-14:

#15

It is not clear that udev is implicated here, the first instance seems to be:

This implies a memory balloon event is occuring. Udev is likely a victim of whatever locks are held by that.

Revision history for this message

Andy Whitcroft (apw) wrote on 2014-03-14:

#16

Note that these come in pairs, the udev seems to be trying to look at the device the balloon driver is trying to make, so this makes sense:

    [ 240.608612] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
    [ 240.608705] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.
    [ 360.633541] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
    [ 360.633724] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.
    [ 480.638445] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
    [ 480.638628] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.
    [ 600.639348] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
    [ 600.639531] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.
    [ 720.652251] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
    [ 720.652434] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.

Can you confirm whether this stops at the 720s point or does it continue indefinatly.

tags:

added: kernel-hyper-v

Revision history for this message

Andy Whitcroft (apw) wrote on 2014-03-14:

#17

Download full text (4.8 KiB)

Stack from kworker:

    [ 240.608612] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
    [ 240.608617] Not tainted 3.13.0-17-generic #37-Ubuntu
    [ 240.608618] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 240.608620] kworker/0:2 D ffff88001e414440 0 861 2 0x00000000
    [ 240.608628] Workqueue: events hot_add_req [hv_balloon]
    [ 240.608630] ffff88001a00fb30 0000000000000002 ffff88001a6f8000 ffff88001a00ffd8
    [ 240.608632] 0000000000014440 0000000000014440 ffff88001a6f8000 ffff88001aac6c98
    [ 240.608635] ffff88001aac6c9c ffff88001a6f8000 00000000ffffffff ffff88001aac6ca0
    [ 240.608637] Call Trace:
    [ 240.608643] [<ffffffff817159f9>] schedule_preempt_disabled+0x29/0x70
    [ 240.608645] [<ffffffff81717865>] __mutex_lock_slowpath+0x135/0x1b0
    [ 240.608647] [<ffffffff817178ff>] mutex_lock+0x1f/0x2f
    [ 240.608651] [<ffffffff8148a5bd>] device_attach+0x1d/0xa0
    [ 240.608653] [<ffffffff81489a38>] bus_probe_device+0x98/0xc0
    [ 240.608656] [<ffffffff81487895>] device_add+0x4c5/0x640
    [ 240.608658] [<ffffffff81487a2a>] device_register+0x1a/0x20
    [ 240.608661] [<ffffffff8149e000>] init_memory_block+0xd0/0xf0
    [ 240.608663] [<ffffffff8149e141>] register_new_memory+0x91/0xa0
    [ 240.608666] [<ffffffff81700d10>] __add_pages+0x140/0x240
    [ 240.608670] [<ffffffff81055649>] arch_add_memory+0x59/0xd0
    [ 240.608672] [<ffffffff81700fe4>] add_memory+0xe4/0x1f0
    [ 240.608675] [<ffffffffa00411cf>] hot_add_req+0x31f/0x1150 [hv_balloon]
    [ 240.608679] [<ffffffff810824a2>] process_one_work+0x182/0x450
    [ 240.608681] [<ffffffff81083241>] worker_thread+0x121/0x410
    [ 240.608683] [<ffffffff81083120>] ? rescuer_thread+0x3e0/0x3e0
    [ 240.608686] [<ffffffff81089ed2>] kthread+0xd2/0xf0
    [ 240.608688] [<ffffffff81089e00>] ? kthread_create_on_node+0x190/0x190
    [ 240.608691] [<ffffffff817219bc>] ret_from_fork+0x7c/0xb0
    [ 240.608693] [<ffffffff81089e00>] ? kthread_create_on_node+0x190/0x190

kworker looks to be blocked on the device lock in device_attach:

int device_attach(struct device *dev)
{
int ret = 0;

device_lock(dev);
[...]
}

If we follow the call trace we take mem_hotplug_mutex in add_memory():

    int __ref add_memory(int nid, u64 start, u64 size)
    {
[...]
        lock_memory_hotplug();
    }

We later call device_add which triggers the udev event for this block:

    int device_add(struct device *dev)
    {
        kobject_uevent(&dev->kobj, KOBJ_ADD);
    [...]
    }

Finally, after emitting this event and and while holding that we call
device_attach() above, nesting the device_lock(dev) inside the memory
hotplug lock.

Stack from systemd-udevd:

Stack from kworker:

[  240.608612] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
    [  240.608617]       Not tainted 3.13.0-17-generic #37-Ubuntu
    [  240.608618] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  240.608620] kworker/0:2     D ffff88001e414440     0   861      2 0x00000000
    [  240.608628] Workqueue: events hot_add_req [hv_balloon]
    [  240.608630]  ffff88001a00fb30 0000000000000002 ffff88001a6f8000 ffff88001a00ffd8
    [  240.608632]  0000000000014440 0000000000014440 ffff88001a6f8000 ffff88001aac6c98
    [  240.608635]  ffff88001aac6c9c ffff88001a6f8000 00000000ffffffff ffff88001aac6ca0
    [  240.608637] Call Trace:
    [  240.608643]  [<ffffffff817159f9>] schedule_preempt_disabled+0x29/0x70
    [  240.608645]  [<ffffffff81717865>] __mutex_lock_slowpath+0x135/0x1b0
    [  240.608647]  [<ffffffff817178ff>] mutex_lock+0x1f/0x2f
    [  240.608651]  [<ffffffff8148a5bd>] device_attach+0x1d/0xa0
    [  240.608653]  [<ffffffff81489a38>] bus_probe_device+0x98/0xc0
    [  240.608656]  [<ffffffff81487895>] device_add+0x4c5/0x640
    [  240.608658]  [<ffffffff81487a2a>] device_register+0x1a/0x20
    [  240.608661]  [<ffffffff8149e000>] init_memory_block+0xd0/0xf0
    [  240.608663]  [<ffffffff8149e141>] register_new_memory+0x91/0xa0
    [  240.608666]  [<ffffffff81700d10>] __add_pages+0x140/0x240
    [  240.608670]  [<ffffffff81055649>] arch_add_memory+0x59/0xd0
    [  240.608672]  [<ffffffff81700fe4>] add_memory+0xe4/0x1f0
    [  240.608675]  [<ffffffffa00411cf>] hot_add_req+0x31f/0x1150 [hv_balloon]
    [  240.608679]  [<ffffffff810824a2>] process_one_work+0x182/0x450
    [  240.608681]  [<ffffffff81083241>] worker_thread+0x121/0x410
    [  240.608683]  [<ffffffff81083120>] ? rescuer_thread+0x3e0/0x3e0
    [  240.608686]  [<ffffffff81089ed2>] kthread+0xd2/0xf0
    [  240.608688]  [<ffffffff81089e00>] ? kthread_create_on_node+0x190/0x190
    [  240.608691]  [<ffffffff817219bc>] ret_from_fork+0x7c/0xb0
    [  240.608693]  [<ffffffff81089e00>] ? kthread_create_on_node+0x190/0x190

kworker looks to be blocked on the device lock in device_attach:

int device_attach(struct device *dev)
    {
	int ret = 0;

device_lock(dev);
	[...]
    }

If we follow the call trace we take mem_hotplug_mutex in add_memory():

int __ref add_memory(int nid, u64 start, u64 size)
    {
	[...]
        lock_memory_hotplug();
    }

We later call device_add which triggers the udev event for this block:

int device_add(struct device *dev)
    {
        kobject_uevent(&dev->kobj, KOBJ_ADD);
    [...]
    }

Finally, after emitting this event and and while holding that we call
device_attach() above, nesting the device_lock(dev) inside the memory
hotplug lock.

Stack from systemd-udevd:

[  240.608705] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.
    [  240.608706]       Not tainted 3.13.0-17-generic #37-Ubuntu
    [  240.608707] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  240.608708] systemd-udevd   D ffff88001e414440     0  1906    404 0x00000004
    [  240.608710]  ffff88001a97bd20 0000000000000002 ffff8800170e0000 ffff88001a97bfd8
    [  240.608712]  0000000000014440 0000000000014440 ffff8800170e0000 ffffffff81c620e0
    [  240.608714]  ffffffff81c620e4 ffff8800170e0000 00000000ffffffff ffffffff81c620e8
    [  240.608716] Call Trace:
    [  240.608719]  [<ffffffff817159f9>] schedule_preempt_disabled+0x29/0x70
    [  240.608721]  [<ffffffff81717865>] __mutex_lock_slowpath+0x135/0x1b0
    [  240.608725]  [<ffffffff8115a8ae>] ? lru_cache_add+0xe/0x10
    [  240.608727]  [<ffffffff817178ff>] mutex_lock+0x1f/0x2f
    [  240.608729]  [<ffffffff817019c3>] online_pages+0x33/0x570
    [  240.608731]  [<ffffffff8149dd98>] memory_subsys_online+0x68/0xd0
    [  240.608733]  [<ffffffff814881e5>] device_online+0x65/0x90
    [  240.608735]  [<ffffffff8149da24>] store_mem_state+0x64/0x160
    [  240.608738]  [<ffffffff81485748>] dev_attr_store+0x18/0x30
    [  240.608742]  [<ffffffff8122e698>] sysfs_write_file+0x128/0x1c0
    [  240.608745]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
    [  240.608747]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
    [  240.608749]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6

udevd seems to be blocked on the hotplug lock:

int __ref online_pages(unsigned long pfn, unsigned long nr_pages, int online_type)
    {
    [...]
	lock_memory_hotplug();
    [...]
	mutex_lock(&zonelists_mutex);
    [...]
    }

Note that udevd would have taken the device lock in device_online():

int device_online(struct device *dev)
    {
        int ret = 0;

device_lock(dev);
    [...]
    }

And while holding this we call online_pages() as above, nesting the memory
hotplug lock inside the device_lock(dev).

This looks to be an ABBA deadlock, assuming dev is the same in these two
cases which seems plausible as we emit the udev event in the middle.

Joseph Salisbury (jsalisbury) on 2014-03-14

Changed in linux (Ubuntu):
importance:	Undecided → Medium
status:	Confirmed → Incomplete
status:	Incomplete → Confirmed

Revision history for this message

Jan Henke (jhe) wrote on 2014-03-15:

#18

Trying to reproduce to confirm the length of the error turns out to be a bit tricky. I currently do not know what exactly triggers this bug. Simply booting the VM again currently does not show that behaviour. As it is apparently related to the Hyper-V ballooning driver, maybe the Hyper-V on Linux guys can help here. I guess there needs to be a certain outside influence to Hyper-V to trigger the bug.

For the 720 seconds above, it is about the timing when I uploaded the files with apport. As the machine was not able to shutdown and hang during the shutdown sequence until I discovered it a few hours later, everything speaks for continuation of the behaviour indefinitely.

Revision history for this message

Samuel Leslie (sdl) wrote on 2014-11-16:

#19

This bug has been quiet for a while by the looks of it so just chipping in. I can confirm I witnessed this bug last week on an Ubuntu 14.04 x64 VM on a Windows Server 2012 R2 Hyper-V server with dynamic memory enabled on the guest. I suspect that dynamic memory (aka. memory hot-add/remove) may be related to this issue. If so, creating a VM with dynamic memory enabled and then running a workload that is memory intensive to ensure the Hyper-V server allocates more RAM to the VM may be beneficial. The tie-in with the balloon driver is interesting, and might suggest there's some level of interaction going on between these two components? Perhaps after dynamic memory adds more RAM to the system the balloon driver may trigger the issue due to no longer valid assumptions, or alternatively, the removal of memory from the system once it no longer needs it has a similar effect?

It may also be useful for others to know that we initially detected this issue due to it causing a very high load average on the affected system which can be trivially detected by monitoring systems like Nagios. Note that while the load average is high, this doesn't correspond to any given process actually consuming substantial CPU resources, so you'll want to take a look at the dmesg output which will confirm if you're experiencing the issue via the blocked systemd-udevd and kworker processes.

Revision history for this message

Andy Whitcroft (apw) wrote on 2014-12-19:

#20

We believe this problem is understood, and Microsoft have a developer working on upstream fixes for this. Initial patches were submitted here: https://lkml.org/lkml/2014/12/2/662, though I believe they are being revised currently.

Revision history for this message

Kartik Subbarao (subbarao) wrote on 2015-06-02:

#21

Does anyone know the current status of this -- is a revised patch still in the works?

Revision history for this message

Dexuan Cui (decui) wrote on 2015-06-03:

#22

The patch has been in the mainline tree:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30467e0b3be83c286d60039f8267dd421128ca74

Can Ubuntu people please check if the patch has been included in Ubuntu?

Joseph Salisbury (jsalisbury) on 2015-07-22

tags:

added: kernel-da-key

Revision history for this message

Thomas Holbrook (f-tom-r) wrote on 2015-07-23:

#23

We also see this issue.. which Ubuntu revision do we need to use to include the patch in the mainline tree. We currently use 14.04.2 LTS.

Revision history for this message

Joseph Salisbury (jsalisbury) wrote on 2015-12-11:

#24

I don't see the patch mentioned in comment #22 in Vivid or Trusty, but I do see it in Wily. Is this bug still an issue for releases prior to Wily?

Changed in linux (Ubuntu Trusty):
importance:	Undecided → Medium
Changed in linux (Ubuntu Vivid):
importance:	Undecided → Medium
Changed in linux (Ubuntu Trusty):
status:	New → Incomplete
Changed in linux (Ubuntu Vivid):
status:	New → Incomplete

Joseph Salisbury (jsalisbury) on 2015-12-11

Changed in linux (Ubuntu):
status:	Confirmed → Incomplete

Revision history for this message

Dexuan Cui (decui) wrote on 2015-12-12:

#25

If the patch has been in Wily, I don't think Wily should have this bug. Please test Wily to confirm this.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2016-02-11:

#26

[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

Launchpad Janitor (janitor) wrote on 2016-02-11:

#27

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

Changed in linux (Ubuntu Vivid):
status:	Incomplete → Expired

Revision history for this message

Launchpad Janitor (janitor) wrote on 2016-02-11:

#28

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

Changed in linux (Ubuntu Trusty):
status:	Incomplete → Expired

Revision history for this message

alex gorbachev (storcium) wrote on 2017-03-15:

#29

Download full text (3.1 KiB)

I just saw a similar issue on Trusty after upgrade to kernel 4.10.2:

Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.926873] INFO: task systemd-udevd:1371 blocked for more than 120 seconds.
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.926926] Not tainted 4.10.2-041002-generic #201703120131
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.926972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927021] systemd-udevd D 0 1371 1266 0x00000004
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927025] Call Trace:
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927034] __schedule+0x233/0x6f0
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927039] ? enqueue_entity+0x113/0x640
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927041] schedule+0x36/0x80
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927044] schedule_timeout+0x22a/0x3f0
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927047] wait_for_completion+0xb4/0x140
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927049] ? wake_up_q+0x80/0x80
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927052] cpuhp_issue_call+0x9e/0xd0
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927053] __cpuhp_setup_state+0xe3/0x160
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927060] ? set_floor_freq_default+0x80/0x80 [intel_rapl]
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927061] ? 0xffffffffc079d000
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927064] rapl_init+0x9e/0x1000 [intel_rapl]
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927066] ? 0xffffffffc079d000
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927070] do_one_initcall+0x52/0x1a0
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927074] ? kmem_cache_alloc_trace+0x142/0x190
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927078] do_init_module+0x5f/0x200
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927084] load_module+0x190b/0x1c70
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927086] ? __symbol_put+0x60/0x60
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927089] ? ima_post_read_file+0x7e/0xa0
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927095] ? security_kernel_post_read_file+0x6b/0x80
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927097] SYSC_finit_module+0xdf/0x110
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927100] SyS_finit_module+0xe/0x10
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927104] entry_SYSCALL_64_fastpath+0x1e/0xad
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927105] RIP: 0033:0x7fe62c321709
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927106] RSP: 002b:00007ffd709ec1f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927109] RAX: ffffffffffffffda RBX: 00000000024c8a80 RCX: 00007fe62c321709
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927110] RDX: 0000000000000000 RSI: 00007fe62d294cf0 RDI: 0000000000000005
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927111] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927112] R10: 0000000000000005 R11: 0000000000000246 R12: 00000000024b3950
Mar 14 22:48:21 roc01r-sca025 kernel: [ 244.927113] R13: 00000000024c8a80 R14: 00000000024b43c0 R15: 000...

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

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

Ubuntulinux package

task systemd-udevd:1906 blocked for more than 120 seconds.

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
linux package